DCA Security FAQ
General Best Practices to Counter Security Threats
Disable Unused Services and Open Ports Investigate all the services running on the system and disable all those that are not required. For example, cups and lp are printer services that are not required. Similarly, remote logins and shells such as telnet, rlogin, should be disabled in favor of ssh. Services such as ftpd, smb, sendmail, the Apache web server may also be considered candidates to be disabled. The following services are required for the DCA. All others should be evaluated and disabled if not required. •acpid •auditd •automount •crond •dsm_sa_datamgrd •dsm_sa_eventmgrd •dsm_sa_snmpd •dca_log_cleanup.py •dsm_om_shrsvcd •gpm •hald •dell_rbu •ipmi driver •irqbalance •dbus-daemon .. •rpc.statd •ntpd •portmap •rpc.idmapd •snmpd •openssh-daemon •syslogd •klogd •xfs Unpatched Services Contact EMC Support for questions about security patch update availability for published software vulnerabilities and inquiries about possible product vulnerabilities. Inattentive Administration Administrators who fail to patch their systems are one of the greatest threats to server security. Recommended best practices around password quality, password expiration, accountability of administrative actions performed, and principle of least privileges must be followed as part of an enterprise security policy. |
System Accounting with auditd
The auditd service is provided for system auditing. By default, the service audits about security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. The audit service, configured with at least its default rules, is strongly recommended for all sites. Note that comprehensive auditing might affect your system's performance. 1.Enable the auditd service Ensure that the auditd service is enabled by running chkconfig auditd on 2.Configure auditd data retention 3.Configure auditd rules for comprehensive auditing # cp /usr/share/doc/audit-1.7.17/stig.rules /etc/audit/audit.rules 4.Record events that modify date and time information Add the following to /etc/audit/audit.rules -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S stime -k time-change -a always,exit -F arch=b64 -S clock_settime -k time-change -w /etc/localtime -p wa -k time-change 5.Record events that modify user/group information Add the following to /etc/audit/audit.rules, to capture events that modify account changes: -w /etc/group -p wa -k identity -w /etc/passwd -p wa -k identity -w /etc/gshadow -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/security/opasswd -p wa -k identity 6.Record attempts to alter logon and logout events The audit system already collects login info for all users and root. To watch for attempted manual edits of files involved in storing logon events, add the following to /etc/audit/audit.rules: -w /var/log/faillog -p wa -k logins -w /var/log/lastlog -p wa -k logins 7.Record attempts to alter process and session initiation information The audit system already collects process information for all users and root. To watch for attempted manual edits of files involved in storing such process information, add the following to /etc/audit/audit.rules: -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k session 8.Ensure auditd collects discretionary access control permission modification events At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules, -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod 9.Ensure auditd collects unauthorized (and unsuccessful) attempts to access files At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access |
Account and Access Control
Greenplum recommends taking the following steps to limit the ability of unauthorized users to gain shell access to privileged accounts. As a matter of best practices, direct root logins should be allowed only for emergency use and for maintenance or upgrade operations. For normal operations, the administrator should access the system as a unique unprivileged account and use su or sudo to execute privileged commands. This improves accountability by ensuring all actions of the administrator are audited. 1.Restrict root logins to system console Verify that the file /etc/security only contains the following entries: The primary system console device: console The virtual console devices: tty1, tty2,... The deprecated virtual console interface may be retained for backward compatibility: vc/1, vc/2,... The serial consoles may be added: ttyS0, ttyS1 2.Block shell and login access for non-root system accounts System accounts are not associated with a human user of the system, typically with UID < 500, and exist to perform some administrative tasks. These accounts should be locked and access to shell restricted to prevent unauthorized users from gaining access to the shell through these accounts. To find all the accounts, UIDs, and shells, run the following command: awk -F: '{print $1 ":" $3 ":" $7}' /etc/passwd Identify all the system accounts, UID < 500, and ensure the accounts are locked and the shells are set to either /sbin/nologin or an invalid value. For the system accounts identified, lock the account and set the shell to /sbin/nologin. usermod -L {system account} usermod -s /sbin/nologin {system account} 3.Limit su access to the root account Ensure the group wheel exists and the usernames of all administrators who should be allowed to execute commands as root are members of that group. grep ^wheel /etc/group Edit the file /etc/pam.d/su to uncomment the line corresponding to the pam_wheel.so module to require a user to be in the wheel group. auth required pam_wheel.so use_uid 4.Configure sudo to improve auditing of root access Edit the file /etc/sudoers to uncomment the line: %wheel ALL=(ALL) ALL 5.Verify all accounts have password fields That is, no account can have an empty password field. awk -F: '($2 == "") {print}' /etc/shadow Lock any account that is output on running this command. 6.Verify all account password hashes are shadowed Verify there are no passwords stored in /etc/passwd, awk -F: '($2 != "x") {print}' /etc/passwd 7.Verify no non-root accounts have UID 0 Verify there is only one password entry for UID 0, which is for the root account. Delete any additional entries that might be listed by running this command. awk -F: '($3 == "0") {print}' /etc/passwd 8.Ensure user home directories are not group-writable or world-readable Verify for each user account, the user's home directory is not SER of the system; verify the permissions of the user's home directory are neither group-writable nor world-readable. No user should ever have write permission to another user's home directory. Group shared directories can be configured in subdirectories or elsewhere in the filesystem if they are needed. 9.Ensure user dot-files are not world-writable For each human user of the system, view the permissions of all dot-files in the user's home directory. 10.Ensure users have sensible umask values Edit the global configuration files /etc/profile, /etc/bashrc, and /etc/csh.cshrc. Add or correct the line: umask 077 Edit the user definitions file /etc/login.defs. Add or correct the line: UMASK 077. View the additional configuration files /etc/csh.login and /etc/profile.d/*, and ensure none of these files redefine the umask to a more permissive value unless there is a good reason for it. |
Verify Permissions on Important Files and Directories
1.Verify permissions on passwd, shadow, group, and gshadow files cd /etc chown root:root passwd shadow group gshadow chmod 644 passwd group chmod 400 shadow gshadow 2.Verify all world-writable directories have sticky bits set Find all the files that are world-writable and do not have their sticky bits set. find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print Set the sticky bit ( # chmod +t {dir} ) for all the directories that result from running the aforementioned command. 3.Find unauthorized world-writable files Find all the files that are world-writable and fix each file listed. find / -xdev -type f -perm -0002 -print Set the right permissions (# chmod o-w {file}) for all the files generated by running the aforementioned command. 4.Find and repair un-owned files Find all the files that do not belong to a valid user or group and either assign an owner or remove the file, as appropriate. find / -xdev \( -nouser -o -nogroup \) -print 5.Verify all world-writable directories have proper ownership Find all the directories that are world-writable and ensure they are owned by either root or a system account (assuming only system accounts have a UID lower than 500). If the command generates any output, verify the assignment is correct or reassign it to root. find / -xdev -type d -perm -0002 -uid +500 -print |
Protect Accounts by Configuring PAM
Authentication settings such as password quality, password expiration policy, password reuse, password retry attempts, and more can be configured using the Pluggable Authentication Modules (PAM) framework. PAM looks in the directory /etc/pam.d for application-specific configuration information. Running authconfig or system-config-authentication will re-write the PAM configuration files, destroying any manually made changes and replacing them with system defaults. 1.Set Password Quality Requirements The default pam_cracklib PAM module provides strength checking for passwords. To configure pam_cracklib to require at least one uppercase character, lowercase character, digit, and special character, as recommended by the U.S. Department of Defense guidelines, edit the file /etc/pam.d/system-auth to include the following parameters in the line corresponding to password requisite pam_cracklib.so try_first_pass retry=3: dcredit=-1. Require at least one digit ucredit=-1. Require at least one upper case character ocredit=-1. Require at least one special character lcredit=-1. Require at least one lower case character minlen-14. Require a minimum password length of 14. For example: password required pam_cracklib.so try_first_pass retry=3\minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 These parameters can be set to reflect your security policy requirements. Note that the password restrictions are not applicable to the root password. 2.Set Lockouts for Failed Password Attempts The pam_tally2 PAM module provides the capability to lock out user accounts after a specified number of failed login attempts. To enforce password lockout, edit the file /etc/pam.d/system-auth to include the following lines: The first of the auth lines should include: auth required pam_tally2.so deny=5 onerr=fail unlock_time=900 The first of the account lines should include: account required pam_tally2.so Here, the deny parameter is set to limit the number of retries to 5 and the unlock_time has been set to 900 seconds to keep the account locked for 900 seconds before it is unlocked. These parameters may be configured appropriately to reflect your security policy requirements. A locked account can be manually unlocked using the pam_tally2 utility: /sbin/pam_tally2 --user {username} -reset 3.Upgrade Password Hashing Algorithm to SHA-512 The default password hashing algorithm used in the system is MD5. To configure the system to use the SHA-512 algorithm, three files need to be edited. •Replace md5 with sha512 in /etc/pam.d/system-auth For example: password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok •Disable MD5_CRYPT_ENAB and set the ENCRYPT_METHOD to SHA512 in /etc/login.defs For example: MD5_CRYPT_ENAB no ENCRYPT_METHOD SHA512 •Update the crypt_style to sha512 in /etc/libuser.conf For example: crypt_style = sha512 The next time a user's password is reset, the password will be generated the SHA-512 algorithm. 4.Limit Password Reuse You can use PAM to limit the reuse of recent passwords. The remember option for the pam_ unix module can be set to remember the recent passwords and prevent their reuse. To accomplish this, edit the appropriate line in /etc/pam.d/system-auth to include the remember option. For example: password sufficient pam_unix.so [ … existing_options …] remember=5 You can set the number of previous passwords to remember to appropriately reflect your security policy requirements. |
Best Practices for Password Management
Best practices for creating and managing user passwords within an organization. 1.Root Password The security of the entire system depends on the strength of the root password. This password should be at least 12 characters long and include a mix of capitalized letters, lowercase letters, special characters, and numbers. It should not be based on any dictionary word. 2.Set Password Expiration Parameters Edit the file /etc/login.defs to specify password expiration settings for new accounts. Add or correct the following lines: PASS_MAX_DAYS 60 — Sets the password to expire after 60 days. PASS_MIN_DAYS 1 — Enforces a 1 day minimum time between password resets. PASS_MIN_LEN 14 — Enforces a minimum password length of 14. PASS_WARN_AGE 7 — Delivers a password expiration warning 7 days before the max_days. For each existing user account, modify the current expiration settings to match the policy: # chage -M 60 -m 7 -W 7 {username} 3.Remove Password Parameters from libuser.conf Ensure the following line exists within the file /etc/libuser.conf under the [import] section. login_defs = /etc/login.defs Ensure no lines in the [userdefaults] section begin with the following text, as these words override settings from /etc/login.defs: LU_SHADOWMAX LU_SHADOWMIN LU_SHADOWWARNING 4.Remove Legacy '+' Entries from Password Files Ensure the following command does not produce any output. Any accounts produced by running this command should be locked. grep "^+:" /etc/passwd /etc/shadow /etc/group |
How to Implement Inactivity Time-out for Login Shells
Configure login shells to automatically log users out after a period of inactivity. The following instructions are not practical for systems that run X Windows, as they will close terminal windows in the X environment. For information about how to automatically lock these systems, follow the Red Hat instructional documentation. The following procedures set up a timeout of 15 seconds. You may adjust the duration appropriately based on your security policy requirements. 1.To implement a timeout for the bash shell, create a new file, tmout.sh under /etc/profile.d with the following content: TMOUT=900 readonly TMOUT export TMOUT 2.To implement a 15-minute idle timeout for the tcsh shell, create a new file, autologout.csh, under /etc/profile.d with the following content: set -r autologout 15 Note that the automatic shell logout occurs only when the shell is the foreground process. For instance, if the session opens an editor, the session does not log out after the timeout period. For remote connections, such as ssh, the timeouts should be set up as part of the sshd configuration options. |
1-7 of 7
