contains 69 rules |
System Settingsgroup |
contains 55 rules |
Installing and Maintaining SoftwaregroupThe following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
contains 9 rules |
Disk PartitioninggroupTo ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/, /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 Partitionrule
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.
identifiers:
CCE-27173-4 references:
SC-32, Test attestation on 20120928 by MM |
Ensure /var Located On Separate PartitionruleThe /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.
identifiers:
CCE-26404-4 references:
SC-32, Test attestation on 20120928 by MM |
Ensure /var/log Located On Separate Partitionrule
System logs are stored in the /var/log directory.
Ensure that it has its own partition or logical
volume at installation time, or migrate it using LVM.
identifiers:
CCE-26967-0 references:
AU-9, SC-32, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20120928 by MM |
Ensure /var/log/audit Located On Separate Partitionrule
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.
identifiers:
CCE-26971-2 references:
AU-4, AU-9, SC-32, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20120928 by MM |
Updating SoftwaregroupThe 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 4 rules |
Ensure Red Hat GPG Key Installedrule
To ensure the system can cryptographically verify base software
packages come from Red Hat (and to connect to the Red Hat Network to
receive them), the Red Hat GPG key must properly be installed.
To install the Red Hat GPG key, run:
$ sudo rhn_register
If the system is not connected to the Internet or an RHN Satellite,
then install the Red Hat GPG key from trusted media such as
the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted
in /media/cdrom, use the following command as the root user to import
it into the keyring:
$ sudo rpm --import /media/cdrom/RPM-GPG-KEY
identifiers:
CCE-26957-1 references:
CM-5(3), SI-7, MA-1(b), 1749, 366, Test attestation on 20150407 by sdw Remediation script:# The two fingerprints below are retrieved from https://access.redhat.com/security/team/key
readonly REDHAT_RELEASE_2_FINGERPRINT="567E 347A D004 4ADE 55BA 8A5F 199E 2F91 FD43 1D51"
readonly REDHAT_AUXILIARY_FINGERPRINT="43A6 E49C 4A38 F4BE 9ABF 2A53 4568 9C88 2FA6 58E0"
# Location of the key we would like to import (once it's integrity verified)
readonly REDHAT_RELEASE_KEY="/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
RPM_GPG_DIR_PERMS=$(stat -c %a "$(dirname "$REDHAT_RELEASE_KEY")")
# Verify /etc/pki/rpm-gpg directory permissions are safe
if [ "${RPM_GPG_DIR_PERMS}" -le "755" ]
then
# If they are safe, try to obtain fingerprints from the key file
# (to ensure there won't be e.g. CRC error)
IFS=$'\n' GPG_OUT=($(gpg --with-fingerprint "${REDHAT_RELEASE_KEY}"))
GPG_RESULT=$?
# No CRC error, safe to proceed
if [ "${GPG_RESULT}" -eq "0" ]
then
for ITEM in "${GPG_OUT[@]}"
do
# Filter just hexadecimal fingerprints from gpg's output from
# processing of a key file
RESULT=$(echo ${ITEM} | sed -n "s/[[:space:]]*Key fingerprint = \(.*\)/\1/p" | tr -s '[:space:]')
# If fingerprint matches Red Hat's release 2 or auxiliary key import the key
if [[ ${RESULT} ]] && ([[ ${RESULT} = "${REDHAT_RELEASE_2_FINGERPRINT}" ]] || \
[[ ${RESULT} = "${REDHAT_AUXILIARY_FINGERPRINT}" ]])
then
rpm --import "${REDHAT_RELEASE_KEY}"
fi
done
fi
fi
|
Ensure gpgcheck Enabled In Main Yum ConfigurationruleThe gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure yum to check package signatures before installing
them, ensure the following line appears in /etc/yum.conf in
the [main] section:
gpgcheck=1
identifiers:
CCE-26989-4 references:
CM-5(3), SI-7, MA-1(b), 1749, 366, Test attestation on 20150407 by sdw |
Ensure gpgcheck Enabled For All Yum Package RepositoriesruleTo ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0
identifiers:
CCE-26876-3 references:
CM-5(3), SI-7, MA-1(b), 1749, 366, Test attestation on 20150407 by sdw |
Ensure Software Patches InstalledruleIf the system is joined to the Red Hat Network, a Red Hat Satellite Server,
or a yum server, run the following command to install updates:
$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages)
can be manually downloaded from the Red Hat Network and installed using rpm.
identifiers:
CCE-26853-2 references:
SI-2, MA-1(b), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20120928 by MM |
Software Integrity Checkinggroup
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system.
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 1 rule |
Verify Integrity with AIDEgroupAIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION.
|
contains 1 rule |
Install AIDErule
Install the AIDE package with the command:
$ sudo yum install aide
identifiers:
CCE-26741-9 references:
CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:yum -y install aide
|
File Permissions and MasksgroupTraditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
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 16 rules |
Verify Permissions on Important Files and
DirectoriesgroupPermissions for many files on a system must be set
restrictively to ensure sensitive information is properly protected.
This section discusses important
permission restrictions which can be verified
to ensure that no harmful discrepancies have
arisen. |
contains 16 rules |
Verify Permissions on Files with Local Account Information and CredentialsgroupThe 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 12 rules |
Verify User Who Owns shadow Filerule
To properly set the owner of /etc/shadow, run the command:
$ sudo chown root /etc/shadow
identifiers:
CCE-26795-5 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chown root /etc/shadow
|
Verify Group Who Owns shadow Filerule
To properly set the group owner of /etc/shadow, run the command:
$ sudo chgrp root xsl:value-of select="@file"/>
identifiers:
CCE-27125-4 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chgrp root /etc/shadow
|
Verify Permissions on shadow Filerule
To properly set the permissions of /etc/shadow, run the command:
$ sudo chmod 0000 /etc/shadow
identifiers:
CCE-27100-7 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chmod 0000 /etc/shadow
|
Verify User Who Owns group Filerule
To properly set the owner of /etc/group, run the command:
$ sudo chown root /etc/group
identifiers:
CCE-26933-2 references:
AC-6, Test attestation on 20121026 by DS Remediation script:chown root /etc/group
|
Verify Group Who Owns group Filerule
To properly set the group owner of /etc/group, run the command:
$ sudo chgrp root xsl:value-of select="@file"/>
identifiers:
CCE-27037-1 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chgrp root /etc/group
|
Verify Permissions on group Filerule
To properly set the permissions of /etc/group, run the command:
$ sudo chmod 644 /etc/group
identifiers:
CCE-26949-8 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chmod 644 /etc/group
|
Verify User Who Owns gshadow Filerule
To properly set the owner of /etc/gshadow, run the command:
$ sudo chown root /etc/gshadow
identifiers:
CCE-27161-9 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chown root /etc/gshadow
|
Verify Group Who Owns gshadow Filerule
To properly set the group owner of /etc/gshadow, run the command:
$ sudo chgrp root xsl:value-of select="@file"/>
identifiers:
CCE-26840-9 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chgrp root /etc/gshadow
|
Verify Permissions on gshadow Filerule
To properly set the permissions of /etc/gshadow, run the command:
$ sudo chmod 0000 /etc/gshadow
identifiers:
CCE-27162-7 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chmod 0000 /etc/gshadow
|
Verify User Who Owns passwd Filerule
To properly set the owner of /etc/passwd, run the command:
$ sudo chown root /etc/passwd
identifiers:
CCE-27138-7 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chown root /etc/passwd
|
Verify Group Who Owns passwd Filerule
To properly set the group owner of /etc/passwd, run the command:
$ sudo chgrp root xsl:value-of select="@file"/>
identifiers:
CCE-26639-5 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chgrp root /etc/passwd
|
Verify Permissions on passwd Filerule
To properly set the permissions of /etc/passwd, run the command:
$ sudo chmod 0644 /etc/passwd
identifiers:
CCE-26887-0 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:chmod 0644 /etc/passwd
|
Verify File Permissions Within Some Important DirectoriesgroupSome directories contain files whose confidentiality or integrity
is notably important and may also be susceptible to misconfiguration over time, particularly if
unpackaged software is installed. As such,
an argument exists to verify that files' permissions within these directories remain
configured correctly and restrictively.
|
contains 4 rules |
Verify that Shared Library Files Have Restrictive PermissionsruleSystem-wide shared library files, which are linked to executables
during process load time or run time, are stored in the following directories
by default:
/lib
/lib64
/usr/lib
/usr/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:
$ sudo chmod go-w FILE
identifiers:
CCE-26966-2 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:DIRS="/lib /lib64 /usr/lib /usr/lib64"
for dirPath in $DIRS; do
find "$dirPath" -perm /022 -type f -exec chmod go-w '{}' \;
done
|
Verify that Shared Library Files Have Root OwnershipruleSystem-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 also
stored in /lib/modules. All files in these directories should be
owned by the root user. If the directory, or any file in these
directories, is found to be owned by a user other than root correct its
ownership with the following command:
$ sudo chown root FILE
identifiers:
CCE-26648-6 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20130914 by swells Remediation script:for LIBDIR in /usr/lib /usr/lib64 /lib /lib64
do
if [ -d $LIBDIR ]
then
find -L $LIBDIR \! -user root -exec chown root {} \;
fi
done
|
Verify that System Executables Have Restrictive Permissionsrule
System executables are stored in the following directories by default:
/bin
/usr/bin
/usr/local/bin
/sbin
/usr/sbin
/usr/local/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:
$ sudo chmod go-w FILE
identifiers:
CCE-27075-1 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx Remediation script:DIRS="/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin"
for dirPath in $DIRS; do
find "$dirPath" -perm /022 -exec chmod go-w '{}' \;
done
|
Verify that System Executables Have Root Ownershiprule
System executables are stored in the following directories by default:
/bin
/usr/bin
/usr/local/bin
/sbin
/usr/sbin
/usr/local/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:
$ sudo chown root FILE
identifiers:
CCE-27119-7 references:
AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx Remediation script:find /bin/ \
/usr/bin/ \
/usr/local/bin/ \
/sbin/ \
/usr/sbin/ \
/usr/local/sbin/ \
\! -user root -execdir chown root {} \;
|
SELinuxgroupSELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
The default SELinux policy, as configured on Red Hat Enterprise Linux 7, 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 unusual requirements which make a stronger policy
appropriate.
|
contains 2 rules |
Ensure SELinux State is EnforcingruleThe SELinux state should be set to enforcing at
system boot time. In the file /etc/selinux/config, add or correct the
following line to configure the system to boot into enforcing mode:
SELINUX=enforcing
identifiers:
CCE-26800-3 references:
AC-3, AC-3(3), AC-4, AC-6, AU-9, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:var_selinux_state="enforcing"
grep -q ^SELINUX= /etc/selinux/config && \
sed -i "s/SELINUX=.*/SELINUX=$var_selinux_state/g" /etc/selinux/config
if ! [ $? -eq 0 ]; then
echo "SELINUX=$var_selinux_state" >> /etc/selinux/config
fi
|
Configure SELinux PolicyruleThe SELinux targeted policy is appropriate for
general-purpose desktops and servers, as well as systems in many other roles.
To configure the system to use this policy, add or correct the following line
in /etc/selinux/config:
SELINUXTYPE=targeted
Other policies, such as mls, provide additional security labeling
and greater confinement but are not compatible with many general-purpose
use cases.
identifiers:
CCE-27135-3 references:
AC-3, AC-3(3), AC-4, AC-6, AU-9, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:var_selinux_policy_name="targeted"
grep -q ^SELINUXTYPE /etc/selinux/config && \
sed -i "s/SELINUXTYPE=.*/SELINUXTYPE=$var_selinux_policy_name/g" /etc/selinux/config
if ! [ $? -eq 0 ]; then
echo "SELINUXTYPE=$var_selinux_policy_name" >> /etc/selinux/config
fi
|
Account and Access ControlgroupIn traditional Unix security, if an attacker gains
shell access to a certain login account, they can perform any action
or access any file to which that account has access. Therefore,
making it more difficult for unauthorized people to gain shell
access to accounts, particularly to privileged accounts, is a
necessary part of securing a system. This section introduces
mechanisms for restricting access to accounts under
Red Hat Enterprise Linux 7. |
contains 23 rules |
Protect Accounts by Restricting Password-Based LogingroupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /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 7 rules |
Restrict Root Loginsgroup
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use 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 2 rules |
Ensure that System Accounts Do Not Run a Shell Upon Loginrule
Some accounts are not associated with a human
user of the system, and exist to perform some administrative
function. Should an attacker be able to log into these accounts,
they should not be granted access to a shell.
The login shell for each local account is stored in the last field of each line
in /etc/passwd. System accounts are those user accounts with a user ID less than
1000. The user ID is stored in the third field.
If any system account SYSACCT (other than root) has a login shell,
disable it with the command:
$ sudo usermod -s /sbin/nologin SYSACCT
identifiers:
CCE-26448-1 references:
AC-2, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS |
Verify Only Root Has UID 0rule
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.
identifiers:
CCE-27175-9 references:
AC-6, IA-2(1), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:awk -F: '$3 == 0 && $1 != "root" { print $1 }' /etc/passwd | xargs passwd -l
|
Verify Proper Storage and Existence of Password
Hashesgroup
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 2 rules |
Prevent Log In to Accounts With Empty PasswordruleIf an account is configured for password authentication
but does not have an assigned password, it may be possible to log
into the account without authentication. Remove any instances of the nullok
option in /etc/pam.d/system-auth to
prevent logins with empty passwords.
identifiers:
CCE-27010-8 references:
IA-5(b), IA-5(c), IA-5(1)(a), Test attestation on 20121024 by DS Remediation script:sed -i 's/\<nullok\>//g' /etc/pam.d/system-auth
|
Verify All Account Password Hashes are Shadowedrule
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.
identifiers:
CCE-27144-5 references:
IA-5(h), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS |
Set Password Expiration ParametersgroupThe 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:
$ sudo chage -M 180 -m 7 -W 7 USER
|
contains 3 rules |
Set Password Minimum Length in login.defsruleTo 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_pwquality) during a password change operation,
then the most restrictive must be satisfied. See PAM section
for more information about enforcing password quality requirements.
identifiers:
CCE-27123-9 references:
IA-5(f), IA-5(1)(a), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:var_accounts_password_minlen_login_defs="6"
grep -q ^PASS_MIN_LEN /etc/login.defs && \
sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN $var_accounts_password_minlen_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_MIN_LEN $var_accounts_password_minlen_login_defs" >> /etc/login.defs
fi
|
Set Password Minimum AgeruleTo 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.
identifiers:
CCE-27002-5 references:
IA-5(f), IA-5(1)(d), 198, 75, Test attestation on 20121026 by DS Remediation script:var_accounts_minimum_age_login_defs="7"
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
|
Set Password Warning AgeruleTo specify how many days prior to password
expiration that a warning will be issued to users,
edit the file /etc/login.defs and add or correct
the following line, replacing DAYS appropriately:
PASS_WARN_AGE DAYS
The DoD requirement is 7.
identifiers:
CCE-26486-1 references:
AC-2(2), IA-5(f), Test attestation on 20121026 by DS Remediation script:var_accounts_password_warn_age_login_defs="7"
grep -q ^PASS_WARN_AGE /etc/login.defs && \
sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE $var_accounts_password_warn_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_WARN_AGE $var_accounts_password_warn_age_login_defs" >> /etc/login.defs
fi
|
Protect Accounts by Configuring PAMgroupPAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
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. |
contains 11 rules |
Set Password Quality RequirementsgroupThe default pam_pwquality 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
pam_pwquality module is the preferred way of configuring
password requirements.
The pam_cracklib PAM module can also provide strength
checking for passwords as the pam_pwquality module.
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 pages pam_pwquality(8) and pam_cracklib(8)
provide information on the capabilities and configuration of
each. |
contains 6 rules |
Set Password Quality Requirements with pam_pwqualitygroupThe pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth:
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth.
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows.
|
contains 6 rules |
Set Password Retry Prompts Permitted Per-SessionruleTo configure the number of retry prompts that are permitted per-session:
Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to
show retry=3, or a lower value if site policy is more restrictive.
The DoD requirement is a maximum of 3 prompts per session.
identifiers:
CCE-27131-2 references:
IA-5(c), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20140925 by swells Remediation script:var_password_pam_retry="3"
if grep -q "retry=" /etc/pam.d/system-auth; then
sed -i --follow-symlink "s/\(retry *= *\).*/\1$var_password_pam_retry/" /etc/pam.d/system-auth
else
sed -i --follow-symlink "/pam_pwquality.so/ s/$/ retry=$var_password_pam_retry/" /etc/pam.d/system-auth
fi
|
Set Password Strength Minimum Digit CharactersruleThe pam_pwquality 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_pwquality will grant +1 additional
length credit for each digit. Modify the dcredit setting in
/etc/security/pwquality.conf to require the use of a digit in passwords.
identifiers:
CCE-27163-5 references:
IA-5(b), IA-5(c), 194, 194, 71, Test attestation on 20121024 by DS Remediation script:var_password_pam_dcredit="1"
if egrep -q ^dcredit[[:space:]]*=[[:space:]]*[-]?[[:digit:]]+ /etc/security/pwquality.conf; then
sed -i "s/^\(dcredit *= *\).*/\1$var_password_pam_dcredit/" /etc/security/pwquality.conf
else
sed -i "/\(dcredit *= *\).*/a dcredit = $var_password_pam_dcredit" /etc/security/pwquality.conf
fi
|
Set Password Strength Minimum Uppercase CharactersruleThe pam_pwquality 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_pwquality will grant +1 additional
length credit for each uppercase character. Modify the ucredit setting in
/etc/security/pwquality.conf to require the use of an uppercase character in passwords.
identifiers:
CCE-26988-6 references:
IA-5(b), IA-5(c), IA-5(1)(a), 192, 69, Test attestation on 20121024 by DS Remediation script:var_password_pam_ucredit="2"
if egrep -q ^ucredit[[:space:]]*=[[:space:]]*[-]?[[:digit:]]+ /etc/security/pwquality.conf; then
sed -i "s/^\(ucredit *= *\).*/\1$var_password_pam_ucredit/" /etc/security/pwquality.conf
else
sed -i "/\(ucredit *= *\).*/a ucredit = $var_password_pam_ucredit" /etc/security/pwquality.conf
fi
|
Set Password Strength Minimum Special CharactersruleThe pam_pwquality 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_pwquality will grant +1
additional length credit for each special character. Modify the ocredit setting in
/etc/security/pwquality.conf to equal 2 to require use of a special character in passwords.
identifiers:
CCE-27151-0 references:
IA-5(b), IA-5(c), IA-5(1)(a), 1619, 266, Test attestation on 20121024 by DS Remediation script:var_password_pam_ocredit="2"
if egrep -q ^ocredit[[:space:]]*=[[:space:]]*[-]?[[:digit:]]+ /etc/security/pwquality.conf; then
sed -i "s/^\(ocredit *= *\).*/\1$var_password_pam_ocredit/" /etc/security/pwquality.conf
else
sed -i "/\(ocredit *= *\).*/a ocredit = $var_password_pam_ocredit" /etc/security/pwquality.conf
fi
|
Set Password Strength Minimum Lowercase CharactersruleThe pam_pwquality 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_pwquality will grant +1 additional
length credit for each lowercase character. Modify the lcredit setting in
/etc/security/pwquality.conf to require the use of a lowercase character in passwords.
identifiers:
CCE-27111-4 references:
IA-5(b), IA-5(c), IA-5(1)(a), 193, 70, Test attestation on 20121024 by DS Remediation script:var_password_pam_lcredit="2"
if egrep -q ^lcredit[[:space:]]*=[[:space:]]*[-]?[[:digit:]]+ /etc/security/pwquality.conf; then
sed -i "s/^\(lcredit *= *\).*/\1$var_password_pam_lcredit/" /etc/security/pwquality.conf
else
sed -i "/\(lcredit *= *\).*/a lcredit = $var_password_pam_lcredit" /etc/security/pwquality.conf
fi
|
Set Password Strength Minimum Different CharactersruleThe pam_pwquality module's difok parameter controls requirements for usage of different
characters during a password change. Modify the difok setting in /etc/security/pwquality.conf
to equal 3 to require differing characters when changing passwords. The DoD requirement is 4.
identifiers:
CCE-26631-2 references:
IA-5(b), IA-5(c), IA-5(1)(b), 195, 72, Test attestation on 20121024 by DS Remediation script:var_password_pam_difok="3"
if egrep -q ^difok[[:space:]]*=[[:space:]]*[-]?[[:digit:]]+ /etc/security/pwquality.conf; then
sed -i "s/^\(difok *= *\).*/\1$var_password_pam_difok/" /etc/security/pwquality.conf
else
sed -i "/\(difok *= *\).*/a difok = $var_password_pam_difok" /etc/security/pwquality.conf
fi
|
Set Lockouts for Failed Password AttemptsgroupThe pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock.
|
contains 2 rules |
Set Deny For Failed Password Attemptsrule
To configure the system to lock out accounts after a number of incorrect login
attempts using pam_faillock.so, modify the content of both
/etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:
add the following line immediately before the pam_unix.so statement in the AUTH section:
auth required pam_faillock.so preauth silent deny=5 unlock_time=604800 fail_interval=900 add the following line immediately after the pam_unix.so statement in the AUTH section:
auth [default=die] pam_faillock.so authfail deny=5 unlock_time=604800 fail_interval=900 add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
account required pam_faillock.so
identifiers:
CCE-26891-2 references:
AC-7(a), 44, 21 Remediation script:var_accounts_passwords_pam_faillock_deny="5"
AUTH_FILES[0]="/etc/pam.d/system-auth"
AUTH_FILES[1]="/etc/pam.d/password-auth"
for pamFile in "${AUTH_FILES[@]}"
do
# pam_faillock.so already present?
if grep -q "^auth.*pam_faillock.so.*" $pamFile; then
# pam_faillock.so present, deny directive present?
if grep -q "^auth.*[default=die].*pam_faillock.so.*authfail.*deny=" $pamFile; then
# both pam_faillock.so & deny present, just correct deny directive value
sed -i --follow-symlink "s/\(^auth.*required.*pam_faillock.so.*preauth.*silent.*\)\(deny *= *\).*/\1\2$var_accounts_passwords_pam_faillock_deny/" $pamFile
sed -i --follow-symlink "s/\(^auth.*[default=die].*pam_faillock.so.*authfail.*\)\(deny *= *\).*/\1\2$var_accounts_passwords_pam_faillock_deny/" $pamFile
# pam_faillock.so present, but deny directive not yet
else
# append correct deny value to appropriate places
sed -i --follow-symlink "/^auth.*required.*pam_faillock.so.*preauth.*silent.*/ s/$/ deny=$var_accounts_passwords_pam_faillock_deny/" $pamFile
sed -i --follow-symlink "/^auth.*[default=die].*pam_faillock.so.*authfail.*/ s/$/ deny=$var_accounts_passwords_pam_faillock_deny/" $pamFile
fi
# pam_faillock.so not present yet
else
# insert pam_faillock.so preauth & authfail rows with proper value of the 'deny' option
sed -i --follow-symlink "/^auth.*sufficient.*pam_unix.so.*/i auth required pam_faillock.so preauth silent deny=$var_accounts_passwords_pam_faillock_deny" $pamFile
sed -i --follow-symlink "/^auth.*sufficient.*pam_unix.so.*/a auth [default=die] pam_faillock.so authfail deny=$var_accounts_passwords_pam_faillock_deny" $pamFile
sed -i --follow-symlink "/^account.*required.*pam_unix.so/i account required pam_faillock.so" $pamFile
fi
done
|
Limit Password ReuseruleDo 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=5 to the
line which refers to the pam_unix.so module, as shown:
password sufficient pam_unix.so existing_options remember=5
The DoD STIG requirement is 5 passwords. identifiers:
CCE-26923-3 references:
IA-5(f), IA-5(1)(e), 200, 77, Test attestation on 20121024 by DS Remediation script:var_password_pam_unix_remember="5"
if grep -q "remember=" /etc/pam.d/system-auth; then
sed -i --follow-symlink "s/\(remember *= *\).*/\1$var_password_pam_unix_remember/" /etc/pam.d/system-auth
else
sed -i --follow-symlink "/^password[[:space:]]\+sufficient[[:space:]]\+pam_unix.so/ s/$/ remember=$var_password_pam_unix_remember/" /etc/pam.d/system-auth
fi
|
Set Password Hashing AlgorithmgroupThe system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
contains 3 rules |
Set Password Hashing Algorithm in /etc/pam.d/system-authrule
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.
identifiers:
CCE-27104-9 references:
IA-5(b), IA-5(c), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:if ! grep -q "^password.*sufficient.*pam_unix.so.*sha512" /etc/pam.d/system-auth; then
sed -i --follow-symlink "/^password.*sufficient.*pam_unix.so/ s/$/ sha512/" /etc/pam.d/system-auth
fi
|
Set Password Hashing Algorithm in /etc/login.defsrule
In /etc/login.defs, add or correct the following line to ensure
the system will use SHA-512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
identifiers:
CCE-27124-7 references:
IA-5(b), IA-5(c), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:if grep --silent ^ENCRYPT_METHOD /etc/login.defs ; then
sed -i 's/^ENCRYPT_METHOD.*/ENCRYPT_METHOD SHA512/g' /etc/login.defs
else
echo "" >> /etc/login.defs
echo "ENCRYPT_METHOD SHA512" >> /etc/login.defs
fi
|
Set Password Hashing Algorithm in /etc/libuser.confrule
In /etc/libuser.conf, add or correct the following line in its
[defaults] section to ensure the system will use the SHA-512
algorithm for password hashing:
crypt_style = sha512
identifiers:
CCE-27053-8 references:
IA-5(b), IA-5(c), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS |
Protect Physical Console AccessgroupIt is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
contains 5 rules |
Set Boot Loader PasswordgroupDuring the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default Red Hat Enterprise Linux boot loader for x86 systems is called GRUB2.
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 4 rules |
Verify /boot/grub2/grub.cfg User OwnershipruleThe file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg, run the command:
$ sudo chown root /boot/grub2/grub.cfg
identifiers:
CCE-26860-7 references:
AC-6(7), 225, Test attestation on 20121026 by DS Remediation script:chown root /boot/grub2/grub.cfg
|
Verify /boot/grub2/grub.cfg Group OwnershipruleThe file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg, run the command:
$ sudo chgrp root xsl:value-of select="@file"/>
identifiers:
CCE-26812-8 references:
AC-6(7), 225, Test attestation on 20121026 by DS Remediation script:chgrp root /boot/grub2/grub.cfg
|
Verify /boot/grub2/grub.cfg PermissionsruleFile permissions for /boot/grub2/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub2/grub.cfg, run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg
identifiers:
CCE-27054-6 references:
AC-6(7), 225, Test attestation on 20121026 by DS Remediation script:chmod 600 /boot/grub2/grub.cfg
|
Set Boot Loader PasswordruleThe grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
To do so, select a superuser account and password and add them into the
appropriate grub2 configuration file(s) under /etc/grub.d.
Since plaintext passwords are a security risk, generate a hash for the pasword
by running the following command:
$ grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected and insert the returned
password hash into the appropriate grub2 configuration file(s) under
/etc/grub.d immediately after the superuser account.
(Use the output from grub2-mkpasswd-pbkdf2 as the value of
password-hash):
password_pbkdf2 superusers-account password-hash
NOTE: It is recommended not to use common administrator account names like root,
admin, or administrator for the grub2 superuser account.
To meet FISMA Moderate, the bootloader superuser account and password MUST
differ from the root account and password.
Once the superuser account and password have been added, update the
grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub.cfg
NOTE: Do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file.
identifiers:
CCE-26809-4 references:
IA-2(1), IA-5(e), AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS |
Require Authentication for Single User ModeruleSingle-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup. By default, no authentication
is performed if single-user mode is selected.
By default, single-user mode is protected by requiring a password and is set
in /usr/lib/systemd/system/rescue.service.
identifiers:
CCE-27170-0 references:
IA-2(1), AC-3, 213, Test attestation on 20121024 by DS Remediation script:grep -q ^SINGLE /etc/sysconfig/init && \
sed -i "s/SINGLE.*/SINGLE=\/sbin\/sulogin/g" /etc/sysconfig/init
if ! [ $? -eq 0 ]; then
echo "SINGLE=/sbin/sulogin" >> /etc/sysconfig/init
fi
|
Network Configuration and FirewallsgroupMost machines must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
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 4 rules |
firewalldgroupThe dynamic firewall daemon firewalld provides a
dynamically managed firewall with support for network “zones” to assign
a level of trust to a network and its associated connections and interfaces.
It has support for IPv4 and IPv6 firewall settings. It supports Ethernet
bridges and has a separation of runtime and permanent configuration options.
It also has an interface for services or applications to add firewall rules
directly.
A graphical configuration tool, firewall-config, is used to configure
firewalld, which in turn uses iptables tool to communicate
with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than
static because changes to the configuration can be made at anytime and are
immediately implemented. There is no need to save or apply the changes. No
unintended disruption of existing network connections occurs as no part of
the firewall has to be reloaded.
|
contains 2 rules |
Inspect and Activate Default firewalld RulesgroupFirewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network. NetworkManager informs firewalld to which
zone an interface belongs. An interface's assigned zone can be changed by
NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings
which can be quickly applied to a network interface. These are the zones
provided by firewalld sorted according to the default trust level of the
zones from untrusted to trusted:
dropAny incoming network packets are dropped, there is no
reply. Only outgoing network connections are possible.blockAny incoming network connections are rejected with an
icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited
for IPv6. Only network connections initiated from within the system are
possible.publicFor use in public areas. You do not trust the other
computers on the network to not harm your computer. Only selected incoming
connections are accepted.externalFor use on external networks with masquerading enabled
especially for routers. You do not trust the other computers on the network to
not harm your computer. Only selected incoming connections are accepted.dmzFor computers in your demilitarized zone that are
publicly-accessible with limited access to your internal network. Only selected
incoming connections are accepted.workFor use in work areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted.homeFor use in home areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted.internalFor use on internal networks. You mostly trust the
other computers on the networks to not harm your computer. Only selected
incoming connections are accepted.trustedAll network connections are accepted.
It is possible to designate one of these zones to be the default zone. When
interface connections are added to NetworkManager, they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-all
Example output of this command might look like the following:
# firewall-cmd --zone=public --list-all
public
interfaces:
services: mdns dhcpv6-client ssh
ports:
forward-ports:
icmp-blocks: source-quench
To view the network zones currently active, enter the following command as root:
# firewall-cmd --get-service
The following listing displays the result of this command on common Red Hat
Enterprise Linux 7 Server system:
# firewall-cmd --get-service
amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp
high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd
ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn
pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind
samba samba-client smtp ssh telnet tftp tftp-client transmission-client
vnc-server wbem-https
Finally to view the network zones that will be active after the next firewalld
service reload, enter the following command as root:
# firewall-cmd --get-service --permanent
|
contains 1 rule |
Verify firewalld Enabledrule
The firewalld service can be enabled with the following command:
$ sudo systemctl enable firewalld
identifiers:
CCE-RHEL7-CCE-TBD Remediation script:#
# Enable firewalld.service for all systemd targets
#
systemctl enable firewalld.service
#
# Start firewalld.service if not currently running
#
systemctl start firewalld.service
|
Strengthen the Default RulesetgroupThe default rules can be strengthened. The system
scripts that activate the firewall rules expect them to be defined
in configuration files under the /etc/firewalld/services
and /etc/firewalld/zones directories.
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 firewall-cmd program to load in rules under the /etc/firewalld/services
and /etc/firewalld/zones directories.
Instructions apply to both unless otherwise noted. Language and address
conventions for regular firewalld rules are used throughout this section.
|
contains 1 rule |
Set Default firewalld Zone for Incoming PacketsruleTo set the default zone to drop for
the built-in default zone which processes incoming IPv4 and IPv6 packets,
modify the following line in
/etc/firewalld/firewalld.conf to be:
DefaultZone=drop
identifiers:
CCE-RHEL7-CCE-TBD references:
CM-7, 66, 1109, 1154, 1414 |
Uncommon Network ProtocolsgroupThe system includes support for several network
protocols which are not commonly used. Although security vulnerabilities
in kernel networking code are not frequently
discovered, the consequences can be dramatic. Ensuring uncommon
network protocols are disabled reduces the system's risk to attacks
targeted at its implementation of those protocols. |
contains 2 rules |
Disable DCCP Supportrule
The Datagram Congestion Control Protocol (DCCP) is a
relatively new transport layer protocol, designed to support
streaming media and telephony.
To configure the system to prevent the dccp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install dccp /bin/true
identifiers:
CCE-26828-4 references:
CM-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:echo "install dccp /bin/true" > /etc/modprobe.d/dccp.conf
|
Disable SCTP Supportrule
The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the sctp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install sctp /bin/true
identifiers:
CCE-27106-4 references:
CM-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:echo "install sctp /bin/true" > /etc/modprobe.d/sctp.conf
|
System Accounting with auditdgroupThe audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, auditd has modest disk space
requirements, and should not noticeably impact system performance.
NOTE: The Linux Audit daemon auditd can be configured to use
the augenrules program to read audit rules files (*.rules)
located in /etc/audit/rules.d location and compile them to create
the resulting form of the /etc/audit/audit.rules configuration file
during the daemon startup (default configuration). Alternatively, the auditd
daemon can use the auditctl utility to read audit rules from the
/etc/audit/audit.rules configuration file during daemon startup,
and load them into the kernel. The expected behavior is configured via the
appropriate ExecStartPost directive setting in the
/usr/lib/systemd/system/auditd.service configuration file.
To instruct the auditd daemon to use the augenrules program
to read audit rules (default configuration), use the following setting:
ExecStartPost=-/sbin/augenrules --load
in the /usr/lib/systemd/system/auditd.service configuration file.
In order to instruct the auditd daemon to use the auditctl
utility to read audit rules, use the following setting:
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
in the /usr/lib/systemd/system/auditd.service configuration file.
Refer to [Service] section of the /usr/lib/systemd/system/auditd.service
configuration file for further details.
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
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems.html#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages
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 1 rule |
Configure auditd Rules for Comprehensive AuditinggroupThe 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:
$ sudo service auditd restart
|
contains 1 rule |
System Audit Logs Must Have Mode 0640 or Less Permissiverule
Change the mode of the audit log files with the following command:
$ sudo chmod 0640 audit_file
identifiers:
CCE-27004-1 references:
AC-6, AU-1(b), AU-9, IR-5, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:chmod -R 640 /var/log/audit/*
chmod 640 /etc/audit/audit.rules
|
Servicesgroup
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux 7 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 7 system and provides guidance about which
ones can be safely disabled.
Red Hat Enterprise Linux 7 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building Red Hat Enterprise Linux 7 servers, it is highly recommended to select the minimal packages and then build up
the system from there.
|
contains 14 rules |
Obsolete ServicesgroupThis section discusses a number of network-visible
services which have historically caused problems for system
security, and for which disabling or severely limiting the service
has been the best available guidance for some time. As a result of
this, many of these services are not installed as part of Red Hat Enterprise Linux 7
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 firewalld to restrict access to the
vulnerable service to only those remote hosts which have a known
need to use it. |
contains 3 rules |
TelnetgroupThe telnet protocol does not provide confidentiality or integrity
for information transmitted on the network. This includes authentication
information such as passwords. Organizations which use telnet should be
actively working to migrate to a more secure protocol. |
contains 3 rules |
Disable telnet Servicerule
The telnet service configuration file /etc/xinetd.d/telnet
is not created automatically. If it was created manually, check the
/etc/xinetd.d/telnet file and ensure that disable = no
is changed to read disable = yes as follows below:
# description: The telnet server serves telnet sessions; it uses \\
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = yes
}
Then the activation of the telnet service on system boot can be disabled
via the following command:
# systemctl disable telnet.socket
identifiers:
CCE-27158-5 references:
AC-17(8), CM-7, IA-5(1)(c), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20140922 by JL |
Uninstall telnet-server PackageruleThe telnet-server package can be uninstalled with
the following command:
$ sudo yum erase telnet-server identifiers:
CCE-27165-0 references:
AC-17(8), CM-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:if rpm -qa | grep -q telnet-server; then
yum -y remove telnet-server
fi
|
Remove telnet ClientsruleThe telnet client allows users to start connections to other
systems via the telnet protocol. identifiers:
CCE-27039-7 Remediation script:yum -y remove telnet
|
Base ServicesgroupThis section addresses the base services that are installed on a
Red Hat Enterprise Linux 7 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 1 rule |
Disable Automatic Bug Reporting Tool (abrtd)ruleThe Automatic Bug Reporting Tool (abrtd) daemon collects
and reports crash data when an application crash is detected. Using a variety
of plugins, abrtd can email crash reports to system administrators, log crash
reports to files, or forward crash reports to a centralized issue tracking
system such as RHTSupport.
The abrtd service can be disabled with the following command:
$ sudo systemctl disable abrtd
identifiers:
CCE-26872-2 references:
AC-17(8), CM-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20140921 by JL Remediation script:#
# Disable abrtd.service for all systemd targets
#
systemctl disable abrtd.service
#
# Stop abrtd.service if currently running
#
systemctl stop abrtd.service
|
SSH ServergroupThe SSH protocol is recommended for remote login and
remote file transfer. SSH provides confidentiality and integrity
for data exchanged between two systems, as well as server
authentication, through the use of public key cryptography. The
implementation included with the system is called OpenSSH, and more
detailed documentation is available from its website,
http://www.openssh.org. Its server program is called sshd and
provided by the RPM package openssh-server. |
contains 10 rules |
Configure OpenSSH Server if NecessarygroupIf the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file /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 10 rules |
Allow Only SSH Protocol 2ruleOnly 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
identifiers:
CCE-27038-9 references:
AC-17(7), IA-5(1)(c), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:grep -qi ^Protocol /etc/ssh/sshd_config && \
sed -i "s/Protocol.*/Protocol 2/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "Protocol 2" >> /etc/ssh/sshd_config
fi
|
Set SSH Idle Timeout IntervalruleSSH allows administrators to set an idle timeout
interval.
After this interval has passed, the idle user will be
automatically logged out.
To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as
follows:
ClientAliveInterval interval
The timeout interval is given in seconds. To have a timeout
of 15 minutes, set interval to 900.
If a shorter timeout has already been set for the login
shell, that value will preempt any SSH
setting made here. Keep in mind that some processes may stop SSH
from correctly detecting that the user is idle.
identifiers:
CCE-26611-4 references:
AC-2(5), SA-8, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:sshd_idle_timeout_value="300"
grep -qi ^ClientAliveInterval /etc/ssh/sshd_config && \
sed -i "s/ClientAliveInterval.*/ClientAliveInterval $sshd_idle_timeout_value/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "ClientAliveInterval $sshd_idle_timeout_value" >> /etc/ssh/sshd_config
fi
|
Set SSH Client Alive CountruleTo ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set,
edit /etc/ssh/sshd_config as
follows:
ClientAliveCountMax 0
identifiers:
CCE-27066-0 references:
AC-2(5), SA-8, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:grep -qi ^ClientAliveCountMax /etc/ssh/sshd_config && \
sed -i "s/ClientAliveCountMax.*/ClientAliveCountMax 0/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "ClientAliveCountMax 0" >> /etc/ssh/sshd_config
fi
|
Disable SSH Support for .rhosts FilesruleSSH can emulate the behavior of the obsolete rsh
command in allowing users to enable insecure access to their
accounts via .rhosts files.
To ensure this behavior is disabled, add or correct the
following line in /etc/ssh/sshd_config:
IgnoreRhosts yes
identifiers:
CCE-27035-5 references:
AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx Remediation script:grep -qi ^IgnoreRhosts /etc/ssh/sshd_config && \
sed -i "s/IgnoreRhosts.*/IgnoreRhosts yes/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "IgnoreRhosts yes" >> /etc/ssh/sshd_config
fi
|
Disable Host-Based AuthenticationruleSSH's cryptographic host-based authentication is
more secure than .rhosts authentication. However, it is
not recommended that hosts unilaterally trust one another, even
within an organization.
To disable host-based authentication, add or correct the
following line in /etc/ssh/sshd_config:
HostbasedAuthentication no
identifiers:
CCE-26870-6 references:
AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:grep -q ^HostbasedAuthentication /etc/ssh/sshd_config && \
sed -i "s/HostbasedAuthentication.*/HostbasedAuthentication no/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "HostbasedAuthentication no" >> /etc/ssh/sshd_config
fi
|
Disable SSH Root LoginruleThe root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line
in /etc/ssh/sshd_config:
PermitRootLogin no
identifiers:
CCE-26946-4 references:
AC-3, AC-6(2), IA-2(1), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:
SSHD_CONFIG='/etc/ssh/sshd_config'
# Obtain line number of first uncommented case-insensitive occurrence of Match
# block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG
FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG)
# Obtain line number of first uncommented case-insensitive occurence of
# PermitRootLogin directive (possibly prefixed with whitespace) present in
# $SSHD_CONFIG
FIRST_PERMIT_ROOT_LOGIN=$(sed -n '/^[[:space:]]*PermitRootLogin[^\n]*/I{=;q}' $SSHD_CONFIG)
# Case: Match block directive not present in $SSHD_CONFIG
if [ -z "$FIRST_MATCH_BLOCK" ]
then
# Case: PermitRootLogin directive not present in $SSHD_CONFIG yet
if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ]
then
# Append 'PermitRootLogin no' at the end of $SSHD_CONFIG
echo -e "\nPermitRootLogin no" >> $SSHD_CONFIG
# Case: PermitRootLogin directive present in $SSHD_CONFIG already
else
# Replace first uncommented case-insensitive occurrence
# of PermitRootLogin directive
sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG
fi
# Case: Match block directive present in $SSHD_CONFIG
else
# Case: PermitRootLogin directive not present in $SSHD_CONFIG yet
if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ]
then
# Prepend 'PermitRootLogin no' before first uncommented
# case-insensitive occurrence of Match block directive
sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG
# Case: PermitRootLogin directive present in $SSHD_CONFIG and placed
# before first Match block directive
elif [ "$FIRST_PERMIT_ROOT_LOGIN" -lt "$FIRST_MATCH_BLOCK" ]
then
# Replace first uncommented case-insensitive occurrence
# of PermitRootLogin directive
sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG
# Case: PermitRootLogin directive present in $SSHD_CONFIG and placed
# after first Match block directive
else
# Prepend 'PermitRootLogin no' before first uncommented
# case-insensitive occurrence of Match block directive
sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG
fi
fi
|
Disable SSH Access via Empty PasswordsruleTo explicitly disallow remote login from accounts with
empty passwords, add or correct the following line in
/etc/ssh/sshd_config:
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration
should prevent users from being able to assign themselves empty passwords.
identifiers:
CCE-26864-9 references:
AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:grep -qi ^PermitEmptyPasswords /etc/ssh/sshd_config && \
sed -i "s/PermitEmptyPasswords.*/PermitEmptyPasswords no/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "PermitEmptyPasswords no" >> /etc/ssh/sshd_config
fi
|
Enable SSH Warning Bannerrule
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.
identifiers:
CCE-27314-4 references:
AC-8(a), AC-8(c)(1), AC-8(c)(2), AC-8(c)(3), 1384, 1385, 1386, 1387, 1388, 228, Test attestation on 20121024 by DS Remediation script:grep -qi ^Banner /etc/ssh/sshd_config && \
sed -i "s/Banner.*/Banner \/etc\/issue/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "" >> /etc/ssh/sshd_config
echo "Banner /etc/issue" >> /etc/ssh/sshd_config
fi
|
Do Not Allow SSH Environment OptionsruleTo ensure users are not able to present
environment options to the SSH daemon, add or correct the following line
in /etc/ssh/sshd_config:
PermitUserEnvironment no
identifiers:
CCE-26974-6 references:
http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:grep -qi ^PermitUserEnvironment /etc/ssh/sshd_config && \
sed -i "s/PermitUserEnvironment.*/PermitUserEnvironment no/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "PermitUserEnvironment no" >> /etc/ssh/sshd_config
fi
|
Use Only Approved CiphersruleLimit the ciphers to those algorithms which are FIPS-approved.
Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode.
The following line in /etc/ssh/sshd_config
demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.
identifiers:
CCE-27051-2 references:
AC-3, AC-17(2), AU-10(5), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:grep -qi ^Ciphers /etc/ssh/sshd_config && \
sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc" >> /etc/ssh/sshd_config
fi
|