Copyright (c) 2004-2017 UNIX Health Check - All Rights Reserved www.unixhealthcheck.com This is confidential and unpublished work of authorship subject to limited use license agreements and is a trade secret, which is the property of UNIX Health Check (www.unixhealthcheck.com). All use, disclosure and/or reproduction not specifically authorized in writing by UNIX Health Check is strictly prohibited. Any expressed or implied warranties are disclaimed. In no event shall UNIX Health Check be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, loss of use, data, profits, or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of these scripts, even if advised of the possibility of such damage. This report is generated by UNIX Health Check for Red Hat Enterprise Linux. It is an overview of check scripts run on an Red Hat system, and depending on the options selected when the checkall.sh script was run, it will list each check script, the returncode of the check script, the output of the check script and a description. At the end of this report is an overview of all scripts run and a score report. Any individual implementing changes should completely understand the change and deem each change appropriate before it is applied to the system. As a standard rule, please take into consideration the impact on other components before implementing the change. Also, we encourage all to conduct a peer review of all changes before implementation. Most importantly, if the effect of a change is not fully understood, do not implement that change until a satisfactory explanation can be given as to what the effects of the change are. We recommend implementation of one change at a time. The application of many changes all at once will increase the likelihood of confusion, if issues arise. For more information, check website http://www.unixhealthcheck.com. For support, email to support@unixhealthcheck.com. 17.06.01 06/01/2017 11:08:09 PDT -gdvx checkall_server5.xml WARNING and ERROR checks only, skipping inventory scripts. Yes XML 405 server5 (server5.unixhealthcheck.com) 192.168.50.15 on interface ens192 Static 255.255.255.192 192.168.50.1 192.168.52.56 192.168.52.57 8.8.8.8 Red Hat Enterprise Linux Server release 7.3 (Maipo) VMware, Inc. VMware Virtual Platform VMware-58 4c 95 79 72 ee 79 32-6d d8 2b 93 71 52 e6 33 64 bit x86_64 Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz 1 4 4 1 Unavailable 4 16384 MB 8063 (0% in use) 11:08:10 up 51 days, 7:31, 1 user, load average: 0.00, 0.01, 0.05 2017-06-01 11:08:11 0 2 This check script lists all user accounts that have no password set. The best way to avoid user accounts for which no password is set, to log in to the system, remove the "nullok" argument for PAM module pam_unix.so for the auth service in /etc/pam.d/system-auth. This disables all logins with blank passwords on the system. Listing all user accounts with blank passwords: bin daemon adm lp sync shutdown halt mail operator games ftp nobody 2017-06-01 11:08:11 0 2 Check for any files in /etc that can be cleaned up. Often, old copies of configuration files are left behind in folder /etc, that will clutter up the folder. This check script identifies files that can be removed safely. Consider removing the following files and/or folders in /etc: /etc/profile.old /etc/sudoers.orig 2017-06-01 11:08:11 0 2 Check for any files in root directory that can be cleaned up. Often, old files are left behind in the root home directory by system administrators. This check script identifies files that can be safely removed. Consider removing the following files and/or directories: /1 2017-06-01 11:08:11 0 2 Check for any files in ~root/.ssh that can be cleaned up. Often, system administrators may leave behind old copies of files in ~root/.ssh, and this check script will identify any files that can be safely removed. Consider removing the following files in ~root/.ssh: authorized_keys.orig 2017-06-01 11:09:16 0 1 Check if the default user settings in /etc/login.defs are correctly set. File /etc/login.defs is a file that determines defaults for new regular and system user accounts and groups. This check script will verify the entries in /etc/login.defs, and if the items are set appropriately for a secure system. Default attribute PASS_MAX_DAYS in /etc/login.defs is set to 99999, but should be 365 or less. PASS_MAX_DAYS defines the number of days a password is valid. Recommended value is between 90 and 365 days. Default attribute PASS_MIN_DAYS in /etc/login.defs is set to 0, but should be at least 1. PASS_MIN_DAYS defines the number of days between password changes. It should be higher than 0. Default attribute PASS_MIN_LEN in /etc/login.defs is set to 5, but should be at least 9. PASS_MIN_LEN defines the minimum length of a password, which should be between 9 and 20. 2017-06-01 11:09:16 0 1 Check if a nslookup of the hostname can be done. It is best practice to use DNS and to have the hostname correctly added to DNS. This check script will also check if reverse IP lookup is enabled in DNS. It is best practice to also be able to reverse DNS lookup an IP address to a hostname. Hostname server5 could not be found in DNS. 2017-06-01 11:09:17 0 1 Check the INACTIVE item in file /etc/default/useradd. Item INACTIVE in /etc/default/useradd indicates when to change the account to inactive after the password has expired, but hasn't been changed. It is best practice to set it to 14 (days). Item INACTIVE in /etc/default/useradd is set to the default value of -1. Please update the value to 14. 2017-06-01 11:09:17 0 1 Check if the permissions of /etc/default/useradd are correctly set. Quite often, the default permissions are set to 644, meaning that this file is readable for everyone. For increased security, please ensure that only user root can read and write this file, by running: # chmod 600 /etc/default/useradd Permissions on file /etc/default/useradd are set to -rw-r--r-- instead of -rw-------. Run: chmod 600 /etc/default/useradd 2017-06-01 11:09:18 0 1 Check the contents and permissions of /etc/hosts. File /etc/hosts may not be empty. It needs to contain at least the server hostname and IP address. Also, the IPv4 localhost entry should be present: 127.0.0.1 localhost.localdomain localhost This script will alert if any permission or ownership of the /etc/hosts file are incorrect, as well as if the number of entries in /etc/hosts is large. It is recommended to use DNS instead of entering a large number of entries in /etc/hosts. Furthermore, this check script will also make sure no additional entries have been added to the IPv6 and IPv4 localhost entries in /etc/hosts. If used at all, the IPv6 entry in /etc/hosts for localhost, should look like this: ::1 localhost6.localdomain6 localhost6 There are too many entries in /etc/hosts (52). Use DNS instead. 2017-06-01 11:09:18 0 1 Check if the name of user root is correct in /etc/passwd. If a system is cloned it may occur that a different system is mentioned in the GECOS field for user root. If that user then sends out an email it looks like it is originating from the original system, and not from the actual system. Having the hostname in the GECOS field for user root is very useful, to understand from which system an email is originating. The root GECOS field should at least include root and the hostname. Run: usermod -c "root server5" root 2017-06-01 11:09:19 0 1 Check if the HISTFILE variable is set in /etc/profile or /etc/environment to something different than the default .sh_history. By doing this, you can get a history file for each login session for each user. If not set, only one history file per user is written to ~/.sh_history. This will not allow for clear understanding which user exactly used which command during which login session. Therefore, it is recommended to set the histfile for each login session. For more information, see: www.aixhealthcheck.com/blog.php?id=251 Environment variable HISTFILE is not set in /etc/bashrc. 2017-06-01 11:09:20 0 2 Check if ksh is installed. The Korn Shell (ksh) is, besides the Bash Shell (bash), often used for scripts, and it is therefore useful to have it installed on any Linux system. The Korn Shell (ksh) is not installed. Run: yum install ksh 2017-06-01 11:09:20 0 1 Check the size of the /var/log/lastlog file. The file /var/log/lastlog is used by the lastlog command and records the last login time for every user. This file is a sparse file, and is known to grow really big in size, even though it does not use up that much space in the /var file system. If the system reports that the file is over 50 MB, it is best to empty the file, as this will aid in keeping the backup of the /var file system small. The size of /var/log/lastlog is over 50 MB: 56 MB. Run: cp /dev/null /var/log/lastlog 2017-06-01 11:09:21 1 1 Check if the system is vulnerable to the 2016 leap second. Leap seconds are a periodic one-second adjustment of Coordinated Universal Time(UTC) in order to keep a system's time of day close to the mean solar time. However, the Earth's rotation speed varies in response to climatic and geological events, and due to this, UTC leap seconds are irregularly spaced and unpredictable. A leap second insertion is taking place on June 30th, 2015 at 23:59:60. Systems running NTP are generally not vulnerable, however on systems without NTP the leap second may cause the kernel to crash. This check script will indicate if you either need to update the tzdata package and/or if you need to update the NTP version on your system. This script is a copy from https://access.redhat.com/labs/leapsecond/ [INFORMATION] - Installed kernel version: 3.10.0-514.el7.x86_64 - The system is running NTP: ntp-4.2.6p5-25.el7.x86_64 When the leap second occurs, this systems time will be stepped by the kernel. Thus, it is configured to stay in sync with the true/official time. [SUGGESTIONS ON KERNEL] A known issue of kernel is detected and listed below. Refer to the link attached for the remediation steps. - There is a chance that hrtimers may fire early when the leap second is inserted; this issue is documented in <https://access.redhat.com/solutions/2766351>. 2017-06-01 11:10:25 0 1 Check if the noatime mount option has been set for any file systems. If there's a lot of file activity, the system has to update a lot of timestamps, e.g. file creation time (ctime), file last modified time (mtime), and file last access time (atime). File systems with heavy inode access activity due to file opens can have significant performance improvements if the noatime option has been set for those file systems. The atime attribute is sometimes called perhaps the most stupid Unix design idea of all times. Think about this a bit: For every file that is read from the disk, let's do a ... write to the disk! And, for every file that is already cached in memory and which we read from the cache ... do a write to the disk! The performance impact of atime is thus: atime updates are by far the biggest I/O performance deficiency that Unix has today. Getting rid of atime updates would give us more everyday Unix performance than all the pagecache speedups of the past 10 years, _combined_. To check if a file system has been mounted with the noatime option, run: # mount | grep noatime To change a file system to use the noatime mount option, edit /etc/fstab, and add "noatime" as an extra mount option to each ext2/3/4 or xfs file system entry, for example "defaults,noatime". Once updated, save the file, and reboot the server to allow all the file systems to be re-mounted using the noatime mount option. File system / is not using the noatime mount option. File system /boot is not using the noatime mount option. File system /home is not using the noatime mount option. File system /var is not using the noatime mount option. File system /home/jmmdhs is not using the noatime mount option. File system /home/hci is not using the noatime mount option. File system /quovadx is not using the noatime mount option. File system /quovadx/ftpout is not using the noatime mount option. File system /quovadx/archive is not using the noatime mount option. 2017-06-01 11:10:32 7 1 Check if the server is properly time synchronized with its time server. If it is off by more than 10 seconds, this script will generate a warning message. If there is an offset with the timeserver, then check the timeservers in /etc/ntp.conf, and make sure the time servers are correctly listed. To synchronize the time of a server with the time server, run: # service ntpd stop # ntpdate [timeserver] # service ntpd start Note: replace "timeserver" in the command above with the actual hostname of a time server in your environment. The ntpdate service is not enabled at system boot time. Run: systemctl enable ntpdate.service 2017-06-01 11:10:32 0 1 Check if the time server, ntpd, is active, and if the configuration file, /etc/ntp.conf is correct. It is crucial that the time on the physical servers remains synchronized. The most common way to achieve this is through NTP. NTP synchronizes the time on the local server to a centralized time server that can be something public, such as the atomic clock, or a centralized, trusted, time clock within an organization. Either way is acceptable as long as all nodes in the application configuration are synchronized to a known, trusted time source. If utilizing NTP from a public time source, the usage of 3 public servers is recommended to ensure the most accurate time is used. If utilizing a private server, a single node is acceptable, although we recommend to have at least 2 time servers configured in /etc/ntp.conf. In both cases, the connection information (hostname or IP address) is needed for all time server hosts being utilized. If ntpd is not active, use the following command to enable it: # service ntpd restart # chkconfig ntpd on If the time on the server is off by more than 5 minutes, use the ntpdate command to synchronize the time with one of your time servers. Look in /etc/ntp.conf for the time servers configured on your system. To synchronize the time, run: # ntpdate ntpserver Replace "ntpserver" in the command above with an actual NTP server listed in /etc/ntp.conf. You can use the following command to verify that NTP is functional: # ntpq -p The local node's NTP daemon will mark a remote NTP server as trusted after a short period of time (5 - 15 minutes). During this time, the local node's NTP daemon is determining the stability of the remote NTP server. The "*" seen in front of the remote NTP server's name or IP address in the output of ntpq -p command designates the trusted, remote NTP server. All remote NTP servers should have a stratum value less than 10. The stratum value is under the st column in the ntpq -p -n command. In the below example, the remote NTP server, 159.140.213.147, is the trusted, remote NTP server. # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *159.140.213.147 169.254.0.1 3 u 51 64 377 1.085 1.028 0.471 +159.140.213.148 169.254.0.1 3 u 58 64 377 1.280 1.087 0.771 The ntpdate service is not enabled at system boot time. Run: systemctl enable ntpdate.service 2017-06-01 11:10:32 0 1 Check if the correct options are present in /etc/sysconfig/ntpd for the NTP daemon. The following entry should be present in /etc/sysconfig/ntpd: OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid -g" Option -x is used to enable slewing, to slowly adjust the clock if necessary. It is required to run the NTP daemon with the -x option. This option allows for time corrections to be done with the "slew" mechanisms instead larger jumps in time called "steps". Option -u ntp:ntp will drop the user for the NTP daemon from root to ntp. Option -p /var/run/ntpd.pid determines the location of the PID file of the NTP daemon. Option -g will avoid the NTP daemon from stopping if the hardware clock (or chip time) differs more than 1000 seconds from the server clock. Option -g overrides the hardware clock. The additional parameter -g allows for the NTP daemon to survive a larger time gap at startup before shutting down abnormally. If you update /etc/sysconfig/ntpd, be sure to restart the NTP daemon: # service ntpd restart NTP slewing option "-x" is missing in item OPTIONS in /etc/sysconfig/ntpd. NTP pidfile is not set in item OPTIONS in /etc/sysconfig/ntpd. Make sure to add "-p /var/run/ntpd.pid". 2017-06-01 11:10:32 0 1 Check if the slewing option (-x) is enabled for the NTP daemon, ntpd. Slewing is important to enable. This will ensure that any time changes that are required or done so, in a slewing fashion, taking small steps at a time, so no large time changes occur on the system, which often impact any applications depending on correct time settings. If slewing is not enabled, make sure that the -x option is added to /etc/sysconfig/ntp, as follows: OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid -g" Once you have updated this file, restart ntpd: # service ntpd restart Then check if you can see the ntpd daemon active with the -x option: # ps -aef | grep ntpd | grep -v grep ntp 16361 1 0 15:01 ? 00:00:00 ntpd -x -u ntp:ntp -p /var/run/ntpd.pid -g NTP slewing is not enabled. 2017-06-01 11:10:32 0 1 Check if /etc/ntp/step-tickers is empty, so ntpdate will use a time server from /etc/ntp.conf. File /etc/ntp/step-tickers is used by the /etc/rc.d/init.d/ntpdate command, so determine the IP address or hostname to do an initial time synchronization with at boot time. If this file is empty, then it will use a time server configured in /etc/ntp.conf instead. Because ntp.conf needs to contain the time servers already, there is no need to configure these as well in /etc/ntp/step-tickers, and we recommend to leave the file empty instead. File /etc/ntp/step-tickers should be empty. Run: cp -f /dev/null /etc/ntp/step-tickers 2017-06-01 11:10:32 0 1 Check if the synchronization of the hardware clock has been enabled. The parameter SYNC_HWCLOCK will synchronize the local node's internal clock after a successful execution of ntpdate command to a trusted NTP server. n RHEL 5 or earlier, modify the SYNC_HWCLOCK to yes in /etc/sysconfig/ntpd file: # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=yes Starting in RHEL 6, hardware clock synchronization at boot time is handled by the ntpdate service. Modify the SYNC_HWCLOCK to yes in /etc/sysconfig/ntpdate file. # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=yes On RHEL 6 or later, set the ntpdate service to be enabled: # chkconfig ntpdate on # service ntpdate start SYNC_HWCLOCK is not enabled. Add "SYNC_HWCLOCK=yes" to /etc/sysconfig/ntpdate. 2017-06-01 11:10:32 0 1 Check if there is no nullok argument listed for pam_unix.so allowing a user without a password to log in to the system. The PAM configuration option that enables null passwords is the nullok module argument passed to pam_unix.so PAM module. You'll want to remove this argument from any modules of auth type for services that allow login. To avoid allowing user accounts for which no password is set to be able to log into the system, the "nullok" argument for the auth entry for the pam_unix.so module in /etc/pam.d/system-auth should be removed. To create a user account without a password, run: # useradd test # usermod -p "" test Argument nullok is listed for pam_unix.so for the auth service type in file /etc/pam.d/system-auth. This allows users without a password to log in to the system. Please remove argument nullok from this entry. Argument nullok is listed for pam_unix.so for the password service type in file /etc/pam.d/system-auth. This allows users to change their passwords to a null value. Please remove argument nullok from this entry. Argument nullok is listed for pam_unix.so for the auth service type in file /etc/pam.d/password-auth. This allows users without a password to log in to the system. Please remove argument nullok from this entry. Argument nullok is listed for pam_unix.so for the password service type in file /etc/pam.d/password-auth. This allows users to change their passwords to a null value. Please remove argument nullok from this entry. 2017-06-01 11:10:32 0 1 Check if password history checking is enabled through PAM pam_unix.so or pam_pwhistory.so. Depending on the Red Hat Enterprise Linux version used, an argument "remember=20" should be added to either pam_unix.so (for RHEL version 6 or lower) or pam_pwhistory.so (for RHEL 7 and up) to files /etc/pam.d/system-auth and /etc/pam-d/password-auth. This will ensure that password history is kept in file /etc/security/opasswd. We recommend a value of 20, which means the last 20 passwords are kept for user accounts, and cannot be re-used by users, which increases system security. The maximum number of passwords that can be kept is 400. On RHEL7 and up, the following entry should be listed after pam_pwquality.so: password required pam_pwhistory.so remember=20 use_authtok On RHEL6 and below, the following entry should be present after pam_cracklib.so: password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok remember=20 Good sources to read more about password history are: RHEL 6: http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html RHEL 7: http://www.deer-run.com/~hal/linux_passwords_pam.html The pam_pwhistory.so module is missing in file /etc/pam.d/system-auth. Please add after pam_pwquality.so: password required pam_pwhistory.so remember=20 use_authtok The pam_pwhistory.so module is missing in file /etc/pam.d/password-auth. Please add after pam_pwquality.so: password required pam_pwhistory.so remember=20 use_authtok 2017-06-01 11:10:33 1 1 Check if pam_pwquality.so is used, and if so, with the correct entries. The pam_pwquality.so module replaced pam_cracklib.so in version 7 of Red Hat Enterprise Linux, in files /etc/pam.d/system-auth and /etc/pam.d/password-auth. It can be used to determine the password complexity settings for user accounts. As such, this check script only applies to systems running RHEL 7 or higher. We recommend not making any changes to files /etc/pam.d/system-auth and/or /etc/pam.d/password-auth, but instead using file /etc/security/pwquality.conf. We recommend setting the following entries in /etc/security/pwquality.conf: difok = 5 minlen = 9 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1 maxrepeat = 4 gecoscheck = 1 This requires user accounts to have at least a length of 9 characters, and the password should include at least 1 digit, one upper-case letter and one special character. Also, the user is allowed 3 times to set a password (retry=3 is defined in both /etc/pam.d/system-auth and /etc/pam.d/password-auth), and cannot use more than 4 consecutive characters in a password. Finally, a new password should differ at least with 5 characters of the previous password, and a check is done to validate that no words found in the gecos field for the user are part of the new password. Argument minlen is missing in file /etc/security/pwquality.conf. Add "minlen=9" to file /etc/security/pwquality.conf. This argument defines the minimum length of the password. The value should be between 9 and 20. Argument maxrepeat is missing in file /etc/security/pwquality.conf. Add "maxrepeat=4" to file /etc/security/pwquality.conf. This argument defines the maximum number of the same consecutive characters. The default is 0. It should be set between 2 and 4. Argument lcredit is missing in file /etc/security/pwquality.conf. Add "lcredit=-1" to file /etc/security/pwquality.conf. This argument determines the minimum number of lower-case characters in a password. It should be set to -1 specifying at least one lower-case character is required. Argument ucredit is missing in file /etc/security/pwquality.conf. Add "ucredit=-1" to file /etc/security/pwquality.conf. This argument determines the minimum number of upper-case characters in a password. It should be set to -1 specifying at least one upper-case character is required. Argument dcredit is missing in file /etc/security/pwquality.conf. Add "dcredit=-1" to file /etc/security/pwquality.conf. This argument determines the minimum number of digits in a password. It should be set to -1 specifying at least one digit is required. Argument ocredit is missing in file /etc/security/pwquality.conf. Add "ocredit=-1" to file /etc/security/pwquality.conf. This argument determines the minimum number of special characters in a password. It should be set to -1 specifying at least one special character is required. Argument gecoscheck in /etc/security/pwquality.conf is not set to a non-zero value. This argument determines if any words in the gecos field of the user can be used in a password. It should be enabled (set to non-zero). 2017-06-01 11:10:33 0 1 Check if a mydomain entry is present in /etc/postfix/main.cf. The mydomain entry in file /etc/postfix/main.cf is important for the Postfix mail system. Without it, Postfix may not be able to send email properly. The mydomain entry should contain the domain name of the system, for example: mydomain = domain.com After updating /etc/postfix/main.cf, make sure to reload the configuration, so Postfix is aware of the changes, by running: # postfix reload No mydomain entry has been configured in /etc/postfix/main.cf. 2017-06-01 11:10:33 0 1 Check if a myhostname entry is present in /etc/postfix/main.cf. The myhostname entry in /etc/postfix/main.cf is important for the Postfix mail system. Without it, it may not be able to send email. The entry in /etc/postfix/main.cf has to look similar to this: myhostname = hostname.domain.com This check script will also alert if the hostname of the system does not match with the myhostname entry in /etc/postfix/main.cf. After updating /etc/postfix/main.cf, make sure to reload Postfix in order to have it pick up any changes to the main.cf file, by running: # postfix reload No myhostname entry has been configured in /etc/postfix/main.cf. 2017-06-01 11:10:33 0 1 Check if a myorigin entry is not present in /etc/postfix/main.cf. The myorigin entry in /etc/postfix/main.cf can be used for the Postfix mail system, to make it look like email is coming from a different domain. The myorigin parameter specifies the domain that locally-posted mail appears to come from. The default is to append $myhostname, which is fine for small sites. Using the myorigin entry, may also result in the Linux system not being able to deliver email to local email addresses (for users on the Linux system itself). It is therefore recommended to not use the myorigin entry in /etc/postfix/main.cf. After updating the main.cf file, make sure to reload the configuration for Postfix, by running: # postfix reload A myorigin entry has been configured in /etc/postfix/main.cf. It is recommended to comment out this entry or to remove it. 2017-06-01 11:10:34 0 1 This script checks a number of items on /etc/resolv.conf: First, the file should exist. Also, there should be only one domain entry in the file, and only one search entry. There should be a nameserver entry in the file, and no more than 3 entries. The search entry must be 1024 characters or less. The FQDN discovered through the /etc/resolv.conf must be resolvable through DNS. The search order in the search entry should be correct (smaller domains should be listed in /etc/resolv.conf BEFORE larger domains, which they are part of). Besides that, there are several other checks within this script, to ensure that name resolving works properly. FQDN server5.unixhealthcheck.com could not be resolved through DNS. 2017-06-01 11:10:35 0 1 Check if the sharutils package has been installed. The sharutils package contains the GNU shar utilities, a set of tools for encoding and decoding packages of files (in binary or text format) in a special plain text format called shell archives (shar). This format can be sent through e-mail (which can be problematic for regular binary files). Install sharutils if you send binary files through e-mail. The sharutils package is not installed. Run: yum install sharutils 2017-06-01 11:10:35 0 1 Check if SyslogFacility is enabled in /etc/ssh/sshd_config. By default, the following 2 entries in /etc/ssh/sshd_config should be enabled to log messages from the SSH daemon to syslog: SyslogFacility AUTHPRIV LogLevel DEBUG The good thing about enabling these 2 items is, that it will now log all activity via ssh. Once you've enabled these 2 items, restart the SSH daemon, by running: # service sshd restart Also make sure that an entry in /etc/rsyslog.conf (if rsyslog is used on RHEL6 or later) or /etc/syslog.conf (if syslog is used on RHEL5 or earlier) is present that records the authpriv.debug messages to a file. For example: authpriv.* /var/log/secure And make sure that the file that is referenced in /etc/rsyslog.conf or /etc/syslog.conf (/var/log/secure in the example above) exists. Then, make sure that the syslog daemon knows about any modification to /etc/rsyslog.conf or /etc/syslog.conf, by refreshing it: # service rsyslog restart or # service syslogd restart The LogLevel option should be set to DEBUG and should be enabled in /etc/ssh/sshd_config. 2017-06-01 11:10:41 0 1 Check if the commands in the /etc/sudoers file (configuration file for the sudo utility) exist. Having a command in the /etc/sudoers file that does not exist does not make sense. Please make sure to include the full pathname to any command in the /etc/sudoers file. And also make sure to always edit the /etc/sudoers file using the visudo command. This check script will also check any files or folders included using the #include and #includedir directives in /etc/sudoers. Command "/sbin/umount" in file /etc/sudoers does not exist. 2017-06-01 11:10:41 0 1 Check if the necessary defaults have been set in /etc/sudoers. It is a good habit to enable at least 3 default entries in /etc/sudoers: logfile - to determine the location of the sudo log file; log_year - to log the current year in the sudo log file; loglinelen=0 - to avoid wrapping text in the sudo log file (by default, entries in the sudo log file are word-wrapped at 80 characters). So, the following entry can be added to /etc/sudoers, by using the visudo command: Defaults logfile=/var/log/sudo.log, log_year, loglinelen=0 Default option log_year in /etc/sudoers has not been set. Default option loglinelen=0 in /etc/sudoers has not been set. Default option logfile in /etc/sudoers has not been set. 2017-06-01 11:10:41 0 1 Check if any groups defined in /etc/sudoers or any files in /etc/sudoers.d aren't set to primary groups of users. This check script will check for any groups defined in /etc/sudoers and any files in /etc/sudoers.d, and will check if there are any users defined in /etc/passwd that have any of those groups as their primary group. Although it is possible, we recommend that you do not define the primary group of a user as a group known in /etc/sudoers, or any file in /etc/sudoers.d. The reason for this is, that primary groups configured for user accounts are not listed in /etc/group. For example, if the primary group of user "theo" is set to "wheel", and group "wheel" has been added to /etc/sudoers with root access, then by looking at /etc/group, you will not see that user "theo" is a member of group "wheel". You will only see this if you run "groups theo", or if you compare the group ID defined as the primary group for user "theo" in /etc/passwd, with the group ID known in /etc/group. It is easier to recognize if user "theo" has been added to group "wheel" as a secondary group, and his primary group has been set to something else, such as "staff" instead. That way, you can see in /etc/group that "theo" is a member of group "wheel". If this script identifies any users with a primary group that is configured in /etc/sudoers or a file in /etc/sudoers.d, then change the primary group of the user to something else, and add the former primary group as a secondary group to the user account instead. For example, for user "theo": # usermod -g users theo # usermod -a -G wheel theo The following users have group ITS as their primary group and that group is also defined in /etc/sudoers: us40894 us82125 us87865 The following users have group sig as their primary group and that group is also defined in /etc/sudoers: us81803 us50814 us102041 us202000 2017-06-01 11:10:41 0 1 Check if the sysfsutils package is installed. By default, this package is not installed on Red Hat systems. The sysfsutils package is a set of utilities built upon sysfs, a virtual filesystem in Linux kernel versions 2.5_ that exposes a system's device tree. A very useful tool in this package is systool. Installation of package sysfsutils is recommended, so systool can be used on the system. Package sysfsutils is not installed. 2017-06-01 11:10:42 0 1 Check if a shell timeout has been set. Setting a shell timeout prevents unauthorized access. A TMOUT value (higher than 0) should be set in /etc/profile or in /etc/bashrc. No shell timeout set. Set the TMOUT value to a non-zero value in /etc/profile or /etc/bashrc. 2017-06-01 11:10:46 0 1 Check if the most recent TSM / IBM Spectrum Protect backup was successful or not. This check only applies to systems that are backed up by TSM / IBM Spectrum Protect. Sched log file /var/log/backup/dsmsched.log does not exist. 2017-06-01 11:10:48 0 1 Check if the TSM / IBM Spectrum Protect scheduler is active. Check if the scheduler is started at system boot time. Check it the TSM / IBM Spectrum Protect scheduler is started after any update to dsm.sys. This check only applies to systems that are backed up through TSM / IBM Spectrum Protect. TSM / IBM Spectrum Protect scheduler and/or acceptor daemon is not active. 2017-06-01 11:10:48 0 1 Check if package tzdata is up-to-date and any tzdata-java package is the same level as tzdata. This check script will alert if the tzdata package is too old. The tzdata package determines the time zone configuration of the local machine, and due to frequent changes to time zone related information, it is important to keep package tzdata up-to-date. Besides package tzdata, also a package tzdata-java exists, which holds time zone information for Java applications, and may also be installed. This check script will check if the tzdata-java package is of the same version as tzdata. Whenever tzdata is updated, and you have tzdata-java installed, please also update tzdata-java. Package tzdata has version 2016h, while package tzdata-java has version 2016i. Please ensure both packages have the same level. 2017-06-01 11:10:49 0 1 Check if there are user accounts that have no password set. It is recommended to set a password for all user accounts that can login to the system. Note: User accounts without a password can not be used to log in directly to a system, and will display a double exclamation mark in the password field in /etc/shadow. However, if there are other authentication mechanisms configured for an account without a password, such as SSH keys that have been configured, then even if no password is set, someone can log in to the system using that user account. As such, we recommend setting a password for all user accounts. User us50814 has no password set. It is recommended to set a password for this account. 2017-06-01 11:10:49 0 1 Check if the permissions of the /usr/lib folder are correctly set. Permission on folder /usr/lib set to dr-xr-xr-x instead of drwxr-xr-x. Run: chmod 755 /usr/lib 2017-06-01 11:10:53 3 1 Check if there are any updates to be installed through yum. The following command will display if any updates are available for your system: # yum check-update You may also run: # yum list updates If any updates are available, and are okay to be updated, run: # yum update Keeping your system up to date with the latest available updates is important for the stability and security of the system. Packages are available for an update. Run: yum check-update 164 seconds 405 364 5 36 91 % /uhc/checkall_server5.xml