Softpanorama

Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)

RHEL  6.5 Installation Checklist

(version 0.1, July 25, 2013)

Server: ______________________________

  1. Create maintenance partition
  2. Configure Drives in a RAID.  
  3. Install software from RHEL DVD
  4. Graphical GUI Installation steps
  5. Configure  Networks
  6. Install additional packages
  7. Install  add-ons
  8. Configure passwd, groups and user directories
  9. Register server and install patches
  10. Create application specific users and home directories
  11. SAP only specific steps
  12.  Oracle only Specific Steps
  13. Perform initial hardening to satisfy audit req (should be automatic or semiautomatic)
  14. Installation of additional utilities and packages
  15. Create baseline
  16. Anything that I missed

Before You Begin

Before you install a RHEL 5 verify the following:

  1. DRAC card is configured.

  2. You are using for the installation the DVD with SP1 not the original GA release

  3. Server IP addresses corresponds those in DNS.

  4. ???

Step 2. Configure Drives in a RAID. 

Notes:

  1. Raid 10 for drives 1,2 and 3,4
    1. 1,2 (36G drives are OS partition)
    2. 3,4 are application partition
  2. If there are 4 harddrive always use RAID10.
  3. Always use Ext 3 filesystem for all partitions, do not use Reisner (It is default of RHEL 5 SP1)
  4. Do not use LVM. 
  5. Recommended size of the swap is application dependent.
  6. If additional disks are available create Dump partition
  7. Example for SAP:

    sda       135GB

    sda1     Dell Util      31MB              0-3

    sda2     /boot                200MB            4-29            (format ext3)

    sda3     swap                32GB               30-4207

    sda4            Extended        103GB            (rest of disk)

    sda5              103GB (rest of the disk)

     

             /            4GB

            /usr            4GB

            /var            4GB

            /opt            4GB

            /tmp            4GB

            /home            2GB

           /usr/sap/BC1  6GB

           /oracle            2GB

           /sarcheck        300MB

  8. Example for Dell 2950

  9. Anything else that I missed.

Step 3.  Install software from RHEL DVD

  1. Select “Base Technology”
  2. Select redundant "Core Packages"  (to be expanded later)  
  3. Anything else that I missed.

Step 4:  Graphical GUI Installation steps

  1. ____ Configure root password, hostname and domain
     
  2. ___  Disable IPv6
     
  3. ___  Disable Firewall
     
  4. ___  Configure network interfaces (IP, netmask, domain search, default gateway)
     
  5. ___  Enable VNC Remote access
     
  6. ___ Configure a Proxy server in order to access the internet, you must first configure YaST with the correct Proxy information.

     

  7.  ___  Modify default local security policies
     
  8. Anything else that I missed.

Step 5: Configure  NTP, sshd, telnet and vsftpd

Important: Do not forget to disable IPv6

  1. ____ Configure ntp using expert option  by adding  two servers:
  2. ___ Install telnet (non-Kerberos version is second in the list of packages)
  3. ____ Install vsftpd (non-Kerberos version are second in the list of packages)
  4. ____ Configure /etc/vsftpd .conf file
  5. ___ Configure ssh
  6. ___   Modify /etc/hosts           
  7. ___  Modify /etc/services
     
  8. ___ Verify that you can access internet using FireFox.
     

  9. ___ Verify NIC speed
     
  10. Anything else that I missed.

 

Step 6:   Install additional packages (generic post-install staff)

  1. ___ Install java rte sun; libelf
  2. ___ Install /usr/BASFBIN/ utilities
  3. ___ Install version s of ksh93 RPM package (to be used as standard Korn shell for users that prefer ksh)
  4. ___ Install mc  RPM package
     
  5. ___ Verify that screen RPM package is installed (should be installed by default). 
     
  6. ___ Modify crontab as necessary 
     
  7. Anything else that I missed.

 

Step 7: Install add-ons

  1. ___ Install RHELtar 
     
  2. ___ Install standard NTI/RU, operator accounts via script
  3. Anything else that I missed.

Step 8:  Configure groups

  1. ___ Create via Gui the group wheel and enroll into it all active system administrators
  2. ___ Group ntiru should contains only staff members of NTI/RU
     
  3. ___ Group staff should contain application owners
     
  4. ___ Group operators should contain operators

     
  5. Anything else that I missed.

Step 9: Register server and install patches

  1. ___ Check if ZMD package is missing and install it, if necessary
     
  2. ___ Verify that proxy server is correctly configured by accesssing Novell.com via FireFox
     
  3. ___ Register the server using registration code for the server provided by Novell. 
     
  4. ___ Install all the patches:
     
  5. ___ [Cancelled] This step is cancelled until further notice because it looks like kdump is a dangerous daemon to have.
  6. Anything else that I missed.

 

Step 10: Create application specific users and home directories

  1. ___  Create application specific users and directories
     
  2. ___  Create NFS mounts
     
  3. Anything else that I missed.

Step 11: SAP only specific steps

  1. ___  ref notes 958253, 171356, 941735 (sapBC1cfg.sh)
     
  2. ___  For NFS mounts ensure that <new host> is in /etc/exports
     
  3. ___  Make SAP dirs/mount points; mod fstab, mount
     
  4. ___  chown….
     
  5. ___  Install saplocales rpm pkg (linuxlab-locales-2.4-1) “rpm –Uvh  --force linuxlab-locales-2.4-1.x86_64.rpm”
     
  6. ___  modify kern parms: /etc/sysctl.conf.sap
     
  7. Anything else that I missed.

Step 13: Perform initial hardening to satisfy audit req (should be automatic or semiautomatic):

  1. ___ Remove Unnecessary Software Packages (RPMs). A very important step in securing a Linux system is to determine the primary function or role of the Linux server. You should have a detailed knowledge of what is on your system. Otherwise you will have a difficult time to understand what needs to be secured and hence securing your Linux systems proactively won't be that effective. Therefore, it is very critical to look at the default list of software packages and remove unneeded packages or packages that don't comply with your security policy. If you do that you will have less packages to update and to maintain when security alerts and patches are released. For example, you should not have Apache or Samba installed on your system if you don't use them. Also, it is a good practice not to have development packages installed on production servers. FTP and Telnet daemons should be installed if there is a justified business reason for it (SSH/SCP/SFTP should be used instead).

    The idea is to create a Linux image that only contains RPMs needed by the applications, and needed for maintenance and troubleshooting purposes. It may be time-consuming but worth the efforts.

    To get a list of all installed RPMs you can use the following command:

    rpm -qa
    If you want to know more about a particular RPM, run:
    rpm -qi <package_name>
    
    To check for and report potential conflicts and dependencies for deleting a RPM, run:
    rpm -e --test <package_name>
    For information on performing Kickstart installations and how to build an image, see Kickstart Installations for more information. 

    Remove unnnessesary services

    To list all services which are started at bootup using the following command:

    chkconfig --list |grep on
    You will notice that there are quite a lot of services enabled on your system. But many runlevel services (Stand-Alone Services) are not network related services like kudzu which is responsible for detecting and configuring new and/or changed hardware on your system. This service is only run during the boot process.

    Here are examples of Red Hat Runlevel System Services which need to be removed:

    apmd           Advanced Power Management (APM) daemon is used for laptops and some desktops
    isdn           needed if ISDN is being used
    iptables       needed if Netfilter (iptables) Firewall is being used
    ip6tables      needed if ip6tables Firewall is being used
    xinetd         needed if xinetd services are being used, see /etc/xinetd.d/ for list of services
    cups           needed if CUPS is used for the printing system
    sysstat        needed to reset system statistics logs
    audit          needed only if Linux Audit Subsystem (LAuS) should run for collecting system call audit records
    psacct         needed only if kernel process accounting information is needed
    netdump        important if kernel oops data and memory dumps should be sent to a Netdump server for server crashes
    
    
  2. ___  Modify /etc/issue & motd
     
  3. Configure syslog and change in /etc/syslog.conf to point to log server
    1. All linux servers should forward syslog to NTI253.
    2. Verify log rotation (/etc/logrotate.conf)
       
  4. ___  Install Tivoli endpoint.
     
    1. See separate document as for details(/Tivoli/Scott_Notes.doc)
       
  5. ___  SecureID installation.
     
    1. See separate document as for details.
       
  6. Install writable file check script into cron (consult Nikolai about the latest and greatest version)
     
  7. Configure VNC to allow remote administration
     
To accept incoming SSH connections from e.g. nodes rac1cluster, rac2cluster and rac3cluster, add the following line to /etc/hosts.allow:
    sshd: rac1cluster rac2cluster rac3cluster

To accept incoming SSH connections from all servers from a specific network, add the name of the subnet to /etc/hosts.allow. For example:
    sshd: rac1cluster rac2cluster rac3cluster .subnet.example.com

To accept incoming portmap connections from IP address 192.168.0.1 and subnet 192.168.5, add the following line to /etc/hosts.allow:
    portmap: 192.168.0.1 192.168.5.

To accept connections from all servers on subnet .subnet.example.com but not from server cracker.subnet.example.com, you could add the following line to /etc/hosts.allow:
    ALL: .subnet.example.com EXCEPT cracker.subnet.example.com


Here are other examples that show some features of TCP wrapper:

If you just want to restrict ssh connections without configuring or using /etc/hosts.deny, you can add the following entries to /etc/hosts.allow:
    sshd: rac1cluster rac2cluster rac3cluster
    sshd: ALL: DENY

The version of TCP wrapper that comes with Red Hat also supports the extended options documented in the hosts_options(5) man page. Here is an example how an additional program can be spawned in e.g. the /etc/hosts.allow file:
    sshd: ALL : spawn echo "Login from %c to %s" | mail -s "Login Info for %s" log@loghost
For information on the % expansions, see "man 5 hosts_access".

The TCP wrapper is quite flexible. And xinetd provides its own set of host-based and time-based access control functions. You can even tell xinetd to limit the rate of incoming connections. I recommend reading various documentations about the Xinetd super daemon on the Internet.

 

Securing SSH

Many network services like telnet, rlogin, and rsh are vulnerable to eavesdropping which is one of several reasons why SSH should be used instead. Red Hat's default configuration for SSH meets the security requirements for many environments. However, there are a few parameters in /etc/ssh/sshd_config that you may want to change on RHEL and other Linux systems.

The chapter Restricting System Access from Servers and Networks shows how direct logins can be disabled for shared and system accounts including root. But it's prudent to disable direct root logins at the SSH level as well.
PermitRootLogin yes
Also ensure to have privilege separation enabled where the daemon is split into two parts. With privilege separation a small part of the code runs as root and the rest of the code runs in a chroot jail environment. Note that on older RHEL systems this feature can break some functionality, for example see Preventing Accidental Denial of Service.
UsePrivilegeSeparation yes
Since SSH protocol version 1 is not as secure you may want to limit the protocol to version 2 only:
Protocol 2
You may also want to prevent SSH from setting up TCP port and X11 forwarding if you don't need it:
AllowTcpForwarding no
X11Forwarding no
Ensure the StrictModes directive is enabled which checks file permissions and ownerships of some important files in the user's home directory like ~/.ssh, ~/.ssh/authorized_keys etc. If any checks fail, the user won't be able to login.
StrictModes yes
Ensure that all host-based authentications are disabled. These methods should be avoided as primary authentication.
IgnoreRhosts yes
HostbasedAuthentication no
RhostsRSAAuthentication no

Disable sftp if it's not needed:
#Subsystem      sftp    /usr/lib/misc/sftp-server

After changing any directives make sure to restart the sshd daemon:
/etc/init.d/sshd restart
  1. Configure SSH for applications, if necessary (SSH is enabled out of the box in RHEL)
    1. Disable SSH1
       
  2. Verify correctness of home directories permissions
     

    Configure Wheel group -- active adminitrators

    the wheel group and enroll everybody who is authorized to become root into wheel group, no matter what is their primary group.

    Note: this is Linux method of controlling access as linux does not have RBAC.
     

  3. Configure Sudo to allow members of the wheel group to became root
     
  4. Populate all home directories and /root directory with .profile  and .kshrc files  (for bash users this is .bash_profile and .bashrc)

Step 14: Installation of additional utilities and packages

  1. ___  Install DataProtector – (reallocate service port 5555 for D.P.-reboot; RHEL9-install “compress” s/w pkg.)
     
  2. ___  Install Sarcheck

Step 15:  Create baseline

  1. ___ Creation of the baseline of key config files for the server and possibly burning it to CD.
     
    1. We can adopt one of the scripts used in troubleshooting and run it after the installation just before giving the server to application people.
       
    2. Copy all the critical config file to /root/baseline/date directory the way JASS does this on Solaris.
       
  2. ___ Verify the /boot/grub/menu.lst is configured correctly.
     
  3. ___ Check is all online updates are installed:
     
  4. ___  Check and if necessary disable test1, guest and any other unused accounts if any were created during the installation.
Unowned Files

Files not owned by any user or group might not necessarily be a security problem in itself. However, unowned files could pose a security problem in the future. For example, if a new user is created and the new users happens to get the same UID as the unowned files have, then this new user will automatically become the owner of these files.

To locate files not owned by any user or group, use the following command:
find / -path /proc -prune -o -nouser -o -nogroup

 

Checking Accounts

Checking for Unlocked Accounts

It is important that all system and vendor accounts that are not used for logins are locked.

To get a list of unlocked accounts on your system, you can check for accounts that do NOT have an encrypted password string starting with "!" or "*" in the /etc/shadow file. If you lock an account using passwd -l, it will put a '!!' in front of the encrypted password, effectively disabling the password. If you lock an account using usermod -L, it will put a '!' in front of the encrypted password. Many system and shared accounts are usually locked by default by having a '*' or '!!' in the password field which renders the encrypted password into an invalid string.

Hence, to get a list of all unlocked (encryptable) accounts, run:
# egrep -v '.*:\*|:\!' /etc/shadow | awk -F: '{print $1}'
Also make sure all accounts have a 'x' in the password field in /etc/passwd. The following command lists all accounts that do not have a 'x' in the password field:
# grep -v ':x:' /etc/passwd
A 'x' in the password fields means that the password has been shadowed, i.e. the encrypted password has to be looked up in the /etc/shadow file. If the password field in /etc/passwd is empty, then the system will not lookup the shadow file and it will not prompt the user for a password at the login prompt.

Checking for Unused Accounts

All system or vendor accounts that are not being used by users, applications, by the system or by daemons should be removed from the system. You can use the following command to find out if there are any files owned by a specific account:
# find / -path /proc -prune -o -user <account> -ls
The -prune option in this example is used to skip the /proc filesystem.

If you are sure that an account can be deleted, you can remove the account using the following command:
# userdel -r <account>
Without the "-r" option userdel will not delete the user's home directory and mail spool (/var/spool/mail/<user>). Note that many system accounts have no home directory.

Single User Mode Password for root

Some admins suggest to add the following line to the /etc/inittab file to ensure that a root password is required for Single User Mode logons:
  ~~:S:wait:/sbin/sulogin
This works but can be circumvented easily! At the GRUB or LILO prompt you can tell the boot loader to alternate the init program by using the boot params "init=/bin/bash". This will place you at a root shell prompt without a password.

 

Enabling Password Aging

In general I do not recommend that the system enforces password expiration for system and shared accounts. This could lead to outages if an application's account expires:
# su oracle -c id
You are required to change your password immediately (password aged)
Changing password for test
(current) UNIX password:
Rather a corporate policy should govern password changes for system and shared accounts. But for individual user accounts the system should expire the passwords automatically. The following example shows how password expiration can be setup for individual user accounts.

The following files and parameters in the table are used when a new account is created with the useradd command. These settings are recorded for each user account in the /etc/shadow file. Therefore, make sure to configure the following parameters before you create any user accounts using the useradd command:

 
/etc/login.defs PASS_MAX_DAYS 60 Maximum number of days a password is valid.
/etc/login.defs PASS_MIN_DAYS 7 Minimum number of days before a user can change the password since the last change.
/etc/login.defs PASS_MIN_LEN n/a This parameter does not work. It is superseded by the PAM module "pam_cracklib". See Enforcing Stronger Passwords for more information.
/etc/login.defs PASS_WARN_AGE 7 Number of days when the password change reminder starts.
/etc/default/useradd INACTIVE 14 Number of days after password expiration that account is disabled.
/etc/default/useradd EXPIRE   Account expiration date in the format YYYY-MM-DD.

Ensure that the above parameters are changed in the /etc/login.defs and /etc/default/useradd files.

When a user account is created using the useradd command, the parameters listed in the above table are recorded in the /etc/shadow file in the following fields:
<username>:<password>:<date>:PASS_MIN_DAYS:PASS_MAX_DAYS:PASS_WARN_AGE:INACTIVE:EXPIRE:

To create a new user account you can execute the following command:
useradd -c "Test User" -g users test
The -g option specifies the primary group for this account:
# id test
uid=509(test) gid=100(users) groups=100(users)

The settings in /etc/login.defs and /etc/default/useradd are recorded for the test user in the /etc/shadow file as follows:
# grep test /etc/shadow
test:!!:12742:7:60:7:14::

You can change the password aging any time using the chage command.

To disable password aging for system and shared accounts, you can run the following chage command:
# chage -M 99999 <system_account_name>

To get password expiration information:
# chage -l <system_account_name>
For example:
# chage -l test
Minimum:        7
Maximum:        60
Warning:        7
Inactive:       14
Last Change:            Jan 11, 2005
Password Expires:       Mar 12, 2005
Password Inactive:      Mar 26, 2005
Account Expires:        Never

 

Enforcing Stronger Passwords

Practical Considerations

On an audited system it is important to restrict people from using simple passwords that can be cracked too easily. However, if the passwords being enforced are too strong, people will write them down. Strong passwords that are written down are not much safer than weak passwords. Some will argue that strong passwords protect you against e.g. Dictionary Attacks and you can defeat it by locking the accounts after a few failed attempts. However, this is not always an option. As I will show at Locking User Accounts After Too Many Login Failures, locked system accounts could bring down your applications and systems which would be nothing short of a denial of service attack.

Undoubtedly, it is important to practise safe password management. In my opinion, a password should have at least one digit number, one other character, and one upper case letter. But keep in mind not to make it overly complicated.

How to Enforce Stronger Passwords

The pam_cracklib module checks the password against dictionary words and other constraints. Unfortunately, however, the original Linux PAM module pam_cracklib uses a credit mechanism. E.g. if you define password length minlen=10, then you will get 1 credit for e.g. using a single digit number in your password if you defined dredit=1. This means that pam_cracklib will accept a password of the length of minlen-credit. If you don't use a digit number, then the minimum length of the password would be minlen. There was no way to tell the module that a password _must_ include a digit number.

Back in 2000 I wrote a patch for the pam_cracklib module where you can assign negative values to the pam_cracklib parameters lcredit, ucredit, dcredit, and ocredit. Using negative values will disable the credit mechanism. For example, if you define dredit=-1, then the module will only accept a password if it includes at least one digit number and if the password has a length of at least minlen.

Red Hat has finally applied my pam_cracklib patch and you don't have to patch the pam_cracklib module any more. The new pam_cracklib feature works in Red Hat Enterprise Linux 4 and Red Hat Fedora Core 3. This feature is now also included with the Red Hat Enterprise Linux 3 Update 4 and Red Hat Enterprise Linux 2.1 Update 6 release. If the Linux distribution you are using does not use the patched pam_cracklib module yet, you can find the procedure for patching pam_cracklib here.

In the following example I'll assume that you are using the new pam_cracklib module, or that you patched the module if your Linux distribution doesn't include the patched version yet.

The following example shows how to enforce the following password rules:
- Minimum length of password must be 8
- Minimum number of lower case letters must be 1
- Minimum number of upper case letters must be 1
- Minimum number of digits must be 1
- Minimum number of other characters must be 1

 
pam_cracklib.so
 
minlen=8
 
Minimum length of password is 8
 
pam_cracklib.so
 
lcredit=-1
 
Minimum number of lower case letters is 1
 
pam_cracklib.so
 
ucredit=-1
 
Minimum number of upper case letters is 1
 
pam_cracklib.so
 
dcredit=-1
 
Minimum number of digits is 1
 
pam_cracklib.so
 
ocredit=-1
 
Minimum number of other characters is 1
 


To setup these password restrictions, edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib arguments highlighted in blue:
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so
account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    required      /lib/security/$ISA/pam_deny.so
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so

Now verify that the new password restrictions work for new passwords. Simply login to a non-root account and change the password using the passwd command. Note that the above requirements are not enforced if you run the passwd command under root.

NOTE: The /etc/pam.d/system-auth PAM configuration file is auto-generated and contains records which dictate a generic authentication scheme. Keep in mind that authconfig might clobber some changes you made. Since I never run authconfig I usually make changes to this file because it's used by many PAM aware applications. Otherwise I'd have to make changes to many configuration files. Changing system-auth is usually the preferred method. You might even want to disable all execution bits from the /usr/bin/authconfig binary to prevent authconfig from clobbering your changes.

Locking User Accounts After Too Many Login Failures

I do not recommend that the system automatically locks system and shared accounts after too many failed login or su attempts. This could lead to outages if the application's account gets locked due to too many login failures like in this example:
# su oracle -c id
su: incorrect password
#
This could be an easy target for a denial of service attack. At Restricting Direct Login Access for System and Shared Accounts I will show how to disable direct logins for system or shared accounts.

In the following example I will show how to lock only individual user accounts after too many failed su or login attempts.

Add the following two lines highlighted in blue to the /etc/pam.d/system-auth file as shown below:
auth        required      /lib/security/$ISA/pam_env.so
auth        required      /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so
account     required      /lib/security/$ISA/pam_unix.so
account     required      /lib/security/$ISA/pam_tally.so per_user deny=5 no_magic_root reset
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    required      /lib/security/$ISA/pam_deny.so
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so

The first added line counts failed login and failed su attempts for each user. The default location for attempted accesses is recorded in /var/log/faillog.

The second added line specifies to lock accounts automatically after 5 failed login or su attempts (deny=5). The counter will be reset to 0 (reset) on successful entry if deny=n was not exceeded. But you don't want system or shared accounts to be locked after too many login failures (denial of service attack). To exempt system and shared accounts from the deny=n parameter, I added the per_user parameter to the module. The per_user parameter instructs the module NOT to use the deny=n limit for accounts where the maximum number of login failures is set explicitly. For example:
# faillog -u oracle -m -1
# faillog -u oracle
Username   Failures  Maximum  Latest
oracle            0       -1  Fri Dec 10 23:57:55 -0600 2005 on unknown
The faillog command with the option "-m -1" has the effect of not placing a limit on the number of failed logins. To instruct the module to activate the deny=n limit for this account again, run:
# faillog -u oracle -m 0
By default, the maximum number of login failures for each account is set to 0 which instructs pam_tally to use the deny=n parameter. The faillog manual page on my Red Hat system says that selecting maximum number of login failures of 0 will deactivate deny=n for the account. The PAM documentation, however, says that per_user will only work if the .fail_max field contains a non-zero value. After testing both values setting it to -1 worked. Maybe because it's read as a high unsigned value?

To see failed login attempts, run:
# faillog
To unlock an account after too many login failures, run:
# faillog -u <user> -r

Make sure to test these changes thoroughly on your system using e.g. ssh and su, and make sure root does not get locked!

To lock/unlock accounts manually, you can run one of the following commands:
# passwd -l <user>
# usermod -L <user>
# passwd -u <user>
# usermod -U <user>

NOTE:

Since the /var/log/faillog is owned by root and only root can write to the /var/log/faillog file, xscreensaver and vlock won't work correctly. Each time xscreensaver or vlock is executed as a non-root user, you won't be able to do an unlock since these programs can't write to /var/log/faillog. I don't have a good solution for that. I can only think of setting the SUID bits on these programs.

 

Restricting Use of Previous Passwords

The pam_unix module parameter remember can be used to configure the number of previous passwords that cannot be reused. And the pam_cracklib module parameter difok can be used to specify the number of characters hat must be different between the old and the new password.

In the following example I will show how to tell the system that a password cannot be reused for at least 6 months and that at least 3 characters must be different between the old and new password.

Remember that in the chapter Enabling Password Aging we set PASS_MIN_DAYS to 7, which specifies the minimum number of days allowed between password changes. Hence, if we tell pam_unix to remember 26 passwords, then the previously used passwords cannot be reused for at least 6 months (26*7 days).

Here is an example. Edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib and pam_unix arguments:
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so
account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 difok=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow remember=26
password    required      /lib/security/$ISA/pam_deny.so
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so

Restricting Direct Login Access for System and Shared Accounts

On an audited production system it is very important to know who switched to which system or shared account. Therefore it is prudent to restrict direct logins for all system and shared account where more than one individual knows the password. All users should do a direct login using their own account and then switch to the system or shared account. (If you are just interested in restricting direct root SSH logins, see Securing SSH.)

However, there are situations where you have to allow direct logins for system or shared accounts. For example, within an Oracle RAC cluster you have to enable direct ssh logins for oracle. But in such an environment you have to protect the whole cluster as a single entity against incoming ssh connection, i.e. direct oracle logins should not work if you come from a node that is not part of the cluster. In the following example I will show how to achieve this goal as well.

Usually all system and shared accounts have one thing in common, that is they are not in the "users" group. The following example assumes that all individual user accounts are in the "users" group but system and shared accounts like root and oracle are not. If you want to go a step further, a good solution would be to implement a new 'logingroup' users group which would require users to be given explicit access.

In this example I will show how to restrict direct logins for:
- SSH                   (/etc/pam.d/sshd)
- Console Login         (/etc/pam.d/login)
- Graphical Gnome Login (/etc/pam.d/gdm
- or for all logins     (/etc/pam.d/system-auth)

To accomplish this goal I will add the pam_access module to the PAM configuration files listed above. This module provides logdaemon-style login access control based on login names, host names, IP addresses, etc. The PAM module type that has to be used in the configuration files is account. This module type does the authorization, i.e. is the user allowed to login (e.g. time, day)? Don't confuse the PAM module type account with auth which does the authentication, for example checking the password. And the control flag I will use is required. It specifies that Success is required, Failure means that it will still call the remaining modules, but the result is already determined.

For SSH Logins add the pam_access module to /etc/pam.d/sshd as follows:
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_access.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth

For Console Logins add the pam_access module to /etc/pam.d/login as follows:
auth       required     pam_securetty.so
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_access.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_selinux.so close
session    required     pam_stack.so service=system-auth
session    optional     pam_console.so
session    required     pam_selinux.so multiple open

For Graphical Gnome Logins add the pam_access module to /etc/pam.d/gdm as follows:
auth       required     pam_env.so
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_access.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    optional     pam_console.so

Now add the following line to the /etc/security/access.conf configuration file:
-:ALL EXCEPT users :ALL
The /etc/security/access.conf configuration file is read by the pam_access module. This entry specifies that no users are accepted except users that are in the "users" group. Since the pam_access module has been configured for "Authorization" (account) in the above PAM configuration files, it denies direct logins for all accounts except the ones that are in the "users" group.

Now on some systems like Oracle RAC clusters you have to enable direct ssh logins for oracle within the cluster. On such systems you can enable direct ssh logins for oracle within the cluster by adding/changing the following lines in /etc/security/access.conf:
-:ALL EXCEPT users oracle:ALL
-:oracle:ALL EXCEPT rac1cluster.example.com rac2cluster.example.com rac3cluster.example.com
The first line has been edited to include the oracle account which will allow general direct logins. However, the second line specifies that direct logins for oracle are only allowed from Oracle RAC nodes (rac1cluster, rac2cluster, and rac3cluster) that are part of the cluster.

NOTE:

In RHEL4 pam_access is already configured for crond:
# grep pam_access /etc/pam.d/*
/etc/pam.d/crond:account    required   pam_access.so accessfile=/etc/security/access-cron.conf
#
This means that the above entries in /etc/security/access.conf will stop cron from working. Note that it is very prudent to always check whether pam_access is configured for any other service on the system!

To ensure that all users on the system can still run cron jobs you can add the following argument to pam_access in /etc/pam.d/crond:
account    required   pam_access.so accessfile=/etc/security/access-cron.conf
This ensures that the /etc/security/access.conf configuration file is not invoked by crond. Since pam_cracklib does not grant permissions if the configuration file does not exist, execute the following command to create an empty file:
# touch /etc/security/access-cron.conf
Now verify that cron jobs can be launched by any user on the system.

NOTE:

The above example will only work if there exists no "users" account in the /etc/passwd file on the system, which is usually the case. Otherwise you have to either delete the "users" account or you have to designate or create another group name.

 

Restricting su Access to System and Shared Accounts

This chapter shows how to restrict people from su-ing to system and shared accounts even if they know the passwords.

Users usually don't share the passwords of their own accounts but are less hesitant to share it for shared accounts. This chapter helps to mitigate this problem.

The following example shows how to restrict su access to the root, oracle, and postgres account to a specific set of users.

NOTE: The documentation about the pam_wheel module included in many Linux distributions is wrong. For instance, in Red Hat Advanced Server 2.1 the pam_wheel module does not only restrict people from su-ing to the root account like it used to be. It restricts people from su-ing to any account. 

Example for Restricting su Access to root, oracle, and postgres Accounts

Create a new group for each set of users that are allowed to su to the root, oracle, and postgres account:

# groupadd rootmembers
# groupadd oracledba
Add all users who are allowed to su to the root, oracle, and postgres account to the new member groups created above.
The following requirement will be configured:
- Only admin1 should be able to su to root, oracle, and postgres.
- Only oracledba1 should be able to su to oracle.
- Only postgresdba1 should be able to su to postgres.
- No one else on the system should be able to su to any account.
# usermod -G rootmembers adminuser1
# usermod -G oraclemembers oracleuser1
# usermod -G postgresmembers postgreRHELr1

As you probably noted, I did not add adminuser1 to the other member groups. Instead, I will show how to give people in the rootmembers group automatically su access to the oracle and postgres account without adding them to the oraclemembers and postgresmembers groups. I consider root admins an exception. They should not be added to all member groups on the system.

Next add the three authentication lines highlighted in blue to the /etc/pam.d/su file as shown below:
auth       sufficient   /lib/security/$ISA/pam_rootok.so
auth       required     /lib/security/$ISA/pam_stack.so service=system-auth
auth       sufficient   /lib/security/$ISA/pam_stack.so service=su-root-members
auth       sufficient   /lib/security/$ISA/pam_stack.so service=su-other-members
auth       required     /lib/security/$ISA/pam_deny.so
account    required     /lib/security/$ISA/pam_stack.so service=system-auth
password   required     /lib/security/$ISA/pam_stack.so service=system-auth
session    required     /lib/security/$ISA/pam_selinux.so close
session    required     /lib/security/$ISA/pam_stack.so service=system-auth
session    required     /lib/security/$ISA/pam_selinux.so open multiple
session    optional     /lib/security/$ISA/pam_xauth.so
These additional authentication lines specify that nobody should be able to su to any account unless at least one of the PAM services, su-root-members or su-other-members, returns Success. The control flag sufficient means that a Success will bypass the remaining authentication modules and overall Success is returned for the authentication part. Failure means that the failed authentication PAM service is ignored. If both authentication PAM services fail, then the last authentication module pam_deny is invoked which will deny all requests for any available authentication module. This will cause the authentication part to fail for the su command.

Next the new authentication PAM service configuration files /etc/pam.d/su-root-members and /etc/pam.d/su-other-members need to be created.

The file /etc/pam.d/su-root-members referenced in /etc/pam.d/su should read like:
auth       required     /lib/security/pam_wheel.so use_uid group=rootmembers
auth       required     /lib/security/pam_listfile.so item=user sense=allow onerr=fail file=/etc/security/su-rootmembers-access
The file /etc/security/su-rootmembers-access referenced in /etc/pam.d/su-root-members should read like:
root
oracle
postgres
The control flag required which is specified for both modules means that both modules have to return Success. Otherwise this PAM service will return Failure to the "su" PAM service configured in /etc/pam.d/su. The first line returns Success only if the user is in the rootmembers groups. The second line allows only access (sense=allow) to those users specified in /etc/security/rootusername, which is root, oracle, and postgres - these are the only users that will be accepted as a user argument to su. The item=user argument instructs pam_listfile that the entries in /etc/security/rootusername are usernames. If an error occurs, such as an unreadable configuration file, access is denied (onerr=fail).

NOTE: Once su access to root is working for users in the rootmembers, I recommend to avoid making any changes to the /etc/pam.d/su-root-members file in the future. Making a mistake in this file could revoke access to root for all users on the system. That's the reason why I created two PAM service files, /etc/pam.d/su-root-members for people in the rootmembers group, and /etc/pam.d/su-other-members (see below) for all other member groups since you will most probably add more member groups to this file in the future.

Next the file /etc/pam.d/su-other-members referenced in /etc/pam.d/su should be created and read like:
auth       sufficient   /lib/security/pam_stack.so service=su-oracle-members
auth       sufficient   /lib/security/pam_stack.so service=su-postgres-members
auth       required     /lib/security/pam_deny.so
If one of the two PAM services returns Success, it will return Success to the "su" PAM service configured in /etc/pam.d/su. Otherwise the last module will be invoked which will deny all further requests and the authentication fails.

Next the PAM services "su-oracle-members" and "su-postgres-members" have to be created.

The file /etc/pam.d/su-oracle-members referenced in /etc/pam.d/su-other-members should read like:
auth       required     /lib/security/pam_wheel.so use_uid group=oraclemembers
auth       required     /lib/security/pam_listfile.so item=user sense=allow onerr=fail file=/etc/security/su-oraclemembers-access
The file /etc/security/su-oraclemembers-access referenced in /etc/pam.d/su-oracle-members should read like:
oracle


Now verify that adminuser1 can su to root, oracle, and postgres. No one else should be able to su to root. oracleuser1 should be able to su to oracle only, and postgreRHELr1 should be able to su to postgres only. No one else on the system should be able su to any of these accounts even if they know the password.

Step 16.  Anything that I missed

  1. Anything else that I missed.
     

 

Webliography

Linux Security Securing and Hardening Linux Production Systems (Linux Security Cookbook - HOWTO - Guide)