Our TEL team is working with Customer State Bank of India to operationalise one new SSS 3500 that we sold to customer to replace the existing Gen2 GLS2 SSS Storage.
As part of the internal security practices the State Bank of India runs their own scans on all their devices is asking the TEL team to help close the discovered vulnerabilities . For few of the changes sought the DEV team has requested the Tel team to help raise RFE for these so this configs can be tested in dev setup and post which the dev team can confirm if same can be implemented in customers SSS3500 storage.
There are multiple vulnerabilities noted , as per discussion with TEL & Dev team raising at high level 5 RFE where the related vulnerabilities are bunched
Control Objective - 2.21.1. PAM configuration
Control Statement - PAM (Pluggable Authentication Modules) is a service that implements modular authentication modules on UNIX systems. PAM is implemented as a set of shared objects that are loaded and executed when a program needs to authenticate a user. Files for PAM are typically located in the /etc/pam.d directory. PAM must be carefully configured to secure system authentication
Risk/Impact - PAM, if improperly configured can make it easier to intercept passwords or crack them using methods such as brute force attacks,
Recommendations/ Implementation Steps -
Run the following command to install the pam_pwquality module: apt install libpam-pwquality
Edit the file /etc/security/pwquality.conf and add or modify the following line for password length to conform to site policy minlen = 14
Edit the file /etc/security/pwquality.conf and add or modify the following line for password complexity to conform to site policy
minclass = 4
OR
dcredit = -1
ucredit = -1
ocredit = -1
lcredit = -1
Edit the /etc/pam.d/common-password file to include the appropriate options for pam_pwquality.so and to conform to site policy:
password requisite pam_pwquality.so retry=3
Notes:
Additional module options may be set, recommendation requirements only cover including try_first_pass and minlen set to 14 or more.
Settings in /etc/security/pwquality.conf must use spaces around the = symbol.
Edit the /etc/pam.d/common-auth file and add the auth line below:
auth required pam_tally2.so onerr=fail audit silent deny=5 unlock_time=900
Edit the /etc/pam.d/common-account file and add the account lines bellow:
account requisite pam_deny.so account required pam_tally.so
If doesn't work due to bug, To work around this issue you have to add pam_tally2 to the account section account required pam_tally2.so for the counter to reset to 0 when using sudo
Edit the /etc/pam.d/common-password file to include the remember option and conform to site policy as shown:
password required pam_pwhistory.so remember=5
password [success=1 default=ignore] pam_unix.so sha512
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of enabling PAM.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.22.1. Set Shadow Password Suite Parameters
Control Statement - Secure default settings for system and user accounts and their environment.
Risk/Impact - There is a risk of compromise of passwords if password and account policy is not correctly and securely implemented.
Recommendations/ Implementation Steps -
1)Set the PASS_MAX_DAYS parameter to conform to site policy in /etc/login.defs : PASS_MAX_DAYS 45
Modify user parameters for all users with a password set to match: # chage --maxdays 45 <user>
2)Set the PASS_MIN_DAYS parameter to 7 in /etc/login.defs : PASS_MIN_DAYS 7
Modify user parameters for all users with a password set to match: # chage --mindays 7 <user>
3)Set the PASS_WARN_AGE parameter to 7 in /etc/login.defs : PASS_WARN_AGE 14
Modify user parameters for all users with a password set to match: # chage --warndays 14 <user>
4) Run the following command to set the default password inactivity period to 30 days: # useradd -D -f 30
Modify user parameters for all users with a password set to match: # chage --inactive 30 <user>
5) Ensure that any users with a password change date in the future should not be present. If such user exists then correct the date.
6)Run the commands appropriate for your distribution: Set the shell for any accounts returned by the audit to nologin: # usermod -s $(which nologin) <user>
Lock any non root accounts returned by the audit: # usermod -L <user>
The following command will set all system accounts to a non login shell: awk -F: '($1!="root" && $1!="sync" && $1!="shutdown" && $1!="halt" && $1!~/^\+/ && $3<'"$(awk '/^\s*UID_MIN/{print $2}' /etc/login.defs)"' && $7!="'"$(which nologin)"'" && $7!="/bin/false") {print $1}' /etc/passwd | while read user do usermod -s $(which nologin) $user done
The following command will automatically lock not root system accounts: awk -F: '($1!="root" && $1!~/^\+/ && $3<'"$(awk '/^\s*UID_MIN/{print $2}' /etc/login.defs)"') {print $1}' /etc/passwd | xargs -I '{}' passwd -S '{}' | awk '($2!="L" && $2!="LK") {print $1}' | while read user do usermod -L $user done
Notes:
The root, sync, shutdown, and halt users are exempted from requiring a non-login shell.
7)Edit the /etc/bashrc, /etc/profile and /etc/profile.d/*.sh files (and the appropriate files for any other shell supported on your system) and add or edit any umask parameters as follows: readonly TMOUT=900 ; export TMOUT
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing the time for pw changes.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.22.2. Logging and Auditing
Control Statement - The su command allows a user to run a command or shell as another user. The program has been superseded by sudo, which allows for more granular control over privileged access. Normally, the su command can be executed by any user. By uncommenting the pam_wheel.so statement in /etc/pam.d/su, the su command will only allow users in the wheel group to execute su.
Risk/Impact - Restricting the use of su, and using sudo in its place, provides system administrators better control of the escalation of user privileges to execute privileged commands. The sudo utility also provides a better logging and audit mechanism, as it can log each command executed via sudo, whereas su can only record that a user executed the su program.
Recommendations/ Implementation Steps -
Create an empty group that will be specified for use of the su command. The group should be named according to site policy.
groupadd sugroup
Add the following line to the /etc/pam.d/su file, specifying the empty group:
auth required pam_wheel.so use_uid group=sugroup
Note: If the users integrated with PIMS then the control will be NA for the users which are integrated with PIMS
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing this.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.24.1. User and Group Settings
Control Statement - Securing aspects of all the users and groups.
Risk/Impact - There is a risk of compromise of accounts and account information if account policy is not correctly and securely implemented.
Recommendations/ Implementation Steps -
If any accounts in the /etc/shadow file do not have a password, run the following command to lock the account until it can be determined why it does not have a password:
# passwd -l <username>
Also, check to see if the account is logged in and investigate what it is being used for to determine if it needs to be forced off.
Remove any legacy '+' entries from /etc/passwd if they exist.
Remove any legacy '+' entries from /etc/shadow if they exist.
Remove any legacy '+' entries from /etc/group if they exist.
Remove any users other than root with UID 0 or assign them a new UID if appropriate.
If any users' home directories do not exist, create them and make sure the respective user owns the directory. Users without an assigned home directory should be removed or assigned a home directory as appropriate.
Change the ownership of any home directories that are not owned by the defined user to the correct user.
Establish a monitoring policy to report user file permissions, dot file, .forward files, .netrc files, .rhosts files and determine the action to be taken in accordance with site policy.
While the complete removal of .netrc files is recommended if any are required on the system secure permissions must be applied.
Use the grpck command to check for other inconsistencies in the /etc/group file.
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing these permissions.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.25.1. Restrict Cipher list
Control Statement - Based on research conducted at various institutions, it was determined that the symmetric portion of the SSH Transport Protocol (as described in RFC 4253) has security weaknesses that allowed recovery of up to 32 bits of plaintext from a block of ciphertext that was encrypted with the Cipher Block Chaining (CBD) method.
Risk/Impact - Data will be communicated in plain text and unauthorized user may try to perform MitM attack.
Recommendations/ Implementation Steps -
Perform following to configured strong ciphers:
Edit the/etc/ssh/sshd_config file:
vi /etc/ssh/sshd_config
Ciphers aes256-ctr, aes192-ctr, aes128-ctr
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing these permissions.
