When requesting a new Linux systems it used to be a case where someone with a Linux background would “build” a system based upon the specifications given by the requester and based upon a number of pre-defined settings by the Linux team. With the introduction of virtualization and especially with the introduction of self service models the way new systems are “created” has changed enormously.
A Linux system is now often more considered as a necessity for running applications or databases and less of a tangible “thing”. It is often regarded as a almost stateless asset which can be requested, provisioned and decommissioned with a couple of clicks in a self service portal. Specially for teams that work on short development projects or in environments that require quickly up and down scaling to be able to handle a workload this makes a lot of sense.
One of the downsides of this however that systems are “created” and managed by people who might be less security aware than your average Linux system operator. This calls for a more strict security management, a more template based implementation of security. And security starts partially with having a good authentication in place, ensuring you have a strong password and surely not a default welcome1 password.
When requesting an Oracle Linux system based upon the Self Service functionality in Oracle Enterprise Manager the requester will have the ability to state a password desired for the root account. It is however good practice to ensure that the user is forced to change the root password on the newly created Oracle Linux system and that this is in line with the standards that are set for this password.
Commonly newly create Oracle Linux systems in a self service manner will be accessed by the requester seconds after they received the automated message that the system is available. Commonly the requester will login via a SSH session and provide the password the requester has provided during the request phase. (This is, if you allow root to login as SSH and if you allow password based authentication).
A good practice is to run a post-installation script on every newly created machine to change any number of settings you like. This post-installation / first boot script can contain the required actions to enforce a password reset on first login an implement the enforcement of a password complexity policy. As an example of how to script this you can have a look at the below snippet of a wider post-installation / first boot script. You can also find this snippet at Github.
As you can see the script enforces that root will have to reset the password at the next login by executing a chage command against the root account.
Next we will push a number of settings to both /etc/pam.d/passwd as well as /etc/security/pwquality.conf to enforce the quality of a password. As you can see, in the example we do set minlen, minclass, maxsequence and maxrepeat. However you are able to do more specific settings in /etc/security/pwquality.conf , the settings you can set are listed below:
Difok
Number of characters in the new password that must not be present in the old password.
minlen
Minimum acceptable size for the new password (plus one if credits are not disabled which is the default)
dcredit
The maximum credit for having digits in the new password. If less than 0 it is the minimum number of digits in the new password.
ucredit
The maximum credit for having uppercase characters in the new password. If less than 0 it is the minimum number of uppercase characters in the new password.
lcredit
The maximum credit for having lowercase characters in the new password. If less than 0 it is the minimum number of lowercase characters in the new password.
ocredit
The maximum credit for having other characters in the new password. If less than 0 it is the minimum number of other characters in the new password.
minclass
The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others).
maxrepeat
The maximum number of allowed consecutive same characters in the new password. The check is disabled if the value is 0.
maxclassrepeat
The maximum number of allowed consecutive characters of the same class in the new password. The check is disabled if the value is 0.
gecoscheck
Whether to check for the words from the passwd entry GECOS string of the user.The check is enabled if the value is not 0.
dictpath
Path to the cracklib dictionaries. Default is to use the cracklib default.
A Linux system is now often more considered as a necessity for running applications or databases and less of a tangible “thing”. It is often regarded as a almost stateless asset which can be requested, provisioned and decommissioned with a couple of clicks in a self service portal. Specially for teams that work on short development projects or in environments that require quickly up and down scaling to be able to handle a workload this makes a lot of sense.
One of the downsides of this however that systems are “created” and managed by people who might be less security aware than your average Linux system operator. This calls for a more strict security management, a more template based implementation of security. And security starts partially with having a good authentication in place, ensuring you have a strong password and surely not a default welcome1 password.
When requesting an Oracle Linux system based upon the Self Service functionality in Oracle Enterprise Manager the requester will have the ability to state a password desired for the root account. It is however good practice to ensure that the user is forced to change the root password on the newly created Oracle Linux system and that this is in line with the standards that are set for this password.
Commonly newly create Oracle Linux systems in a self service manner will be accessed by the requester seconds after they received the automated message that the system is available. Commonly the requester will login via a SSH session and provide the password the requester has provided during the request phase. (This is, if you allow root to login as SSH and if you allow password based authentication).
A good practice is to run a post-installation script on every newly created machine to change any number of settings you like. This post-installation / first boot script can contain the required actions to enforce a password reset on first login an implement the enforcement of a password complexity policy. As an example of how to script this you can have a look at the below snippet of a wider post-installation / first boot script. You can also find this snippet at Github.
#!/bin/bash # function used to enfore root to reset password on next login. function forceRootPwd { logger "Setting enforced root password change" chage -d 0 root } # function used to ensure the password policy is set function forcePolicy { logger "setting the password policy" echo "password required pam_pwquality.so retry=3" >> /etc/pam.d/passwd echo "minlen = 8" >> /etc/security/pwquality.conf echo "minclass = 4" >> /etc/security/pwquality.conf echo "maxsequence = 3" >> /etc/security/pwquality.conf echo "maxrepeat = 3" >> /etc/security/pwquality.conf } # call the forceRootPwd function forceRootPwd forcePolicy
As you can see the script enforces that root will have to reset the password at the next login by executing a chage command against the root account.
Next we will push a number of settings to both /etc/pam.d/passwd as well as /etc/security/pwquality.conf to enforce the quality of a password. As you can see, in the example we do set minlen, minclass, maxsequence and maxrepeat. However you are able to do more specific settings in /etc/security/pwquality.conf , the settings you can set are listed below:
Difok
Number of characters in the new password that must not be present in the old password.
minlen
Minimum acceptable size for the new password (plus one if credits are not disabled which is the default)
dcredit
The maximum credit for having digits in the new password. If less than 0 it is the minimum number of digits in the new password.
ucredit
The maximum credit for having uppercase characters in the new password. If less than 0 it is the minimum number of uppercase characters in the new password.
lcredit
The maximum credit for having lowercase characters in the new password. If less than 0 it is the minimum number of lowercase characters in the new password.
ocredit
The maximum credit for having other characters in the new password. If less than 0 it is the minimum number of other characters in the new password.
minclass
The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others).
maxrepeat
The maximum number of allowed consecutive same characters in the new password. The check is disabled if the value is 0.
maxclassrepeat
The maximum number of allowed consecutive characters of the same class in the new password. The check is disabled if the value is 0.
gecoscheck
Whether to check for the words from the passwd entry GECOS string of the user.The check is enabled if the value is not 0.
dictpath
Path to the cracklib dictionaries. Default is to use the cracklib default.
No comments:
Post a Comment