Citrix XenServer Security Guidelines

1. Account Management

1.1. Default Accounts (Importance: Medium)

Overview

Check for and delete default accounts that are not used on the system, and any suspicious or unusual accounts.
Delete the accounts listed below, which are known to be unused on most systems, along with any suspicious accounts, and disable login for system accounts that generally do not need to log in.
Accounts created by default when an OS or package is installed often use default passwords and can be abused in password-guessing attacks.

Verification

Check for the existence of lp, uucp, nuucp, suspicious or unusual accounts (for example, guest and test), and unused accounts.

■ Command

# cat /etc/passwd | egrep "lp:|uucp:|nuucp:" | grep -v "lpd"

Configuration

If accounts exist for people who have resigned, transferred, taken leave, or had their contracts terminated, delete them.
Delete lp, uucp, nuucp, suspicious or unusual accounts (for example, guest and test), and unused accounts.
Changing the login shell to /bin/false can create a security problem, so deletion is recommended.

■ Command

# userdel lp
# userdel uucp
# userdel nuucp

1.2. Managing Root Privileges of Regular Accounts (Importance: High)

Overview

For security, the system administrator should regularly inspect and delete suspicious directories and files for every account, including the root account, and periodically review and remove unnecessary user accounts.

Verification

Check whether any regular account other than root has root privileges.
If a UID duplicates root, another user can exercise administrator privileges. When UIDs are duplicated between users, user audit trails are difficult and user privileges overlap.
If a regular account other than root has a UID of ‘0’, delete it or assign an appropriate UID (change it to a number of 100 or higher), and register regular accounts that belong to the root group in a group with appropriate privileges.
Exclude system accounts (daemon, bin, adm, uucp, nuucp, lp, hpdb, and so on).

< Distinguishing regular accounts and their directories * Distinguish them from the contents of the “/etc/passwd “ file >

The following is a sample of the /etc/passwd file. Fields are separated by ”:“. If the third field is “0”, the account has superuser privileges. An account whose value is other than “0” is treated as a regular account. The sixth field is that account’s home directory.

① : Indicates the user account. 
② : Indicates that the password is encrypted and stored in the shadow file. 
③ : The user number. It is 0 because this is the administrator. For a regular user, numbering starts at 500. 
④ : The group ID. It is 0 because this is the administrator group. 
⑤ : The real name. This setting has no particular effect on the system configuration. You may enter your own name. 
⑥ : Sets the user’s home directory. Because this is the administrator, the home directory is /root. 
⑦ : Defines the user’s shell.

<passwd file fields> loginID:x:UID:GID:comment:home_directory:login_shell

Configuration

In the /etc/passwd file, change the UID of any regular account whose UID is 0 to 100 or higher.

■ Command

Example) To change the UID of the wiki account to 2002
# usermod –u 2002 wiki

1.3. passwd File Permission Settings (Importance: High)

Overview

Check whether access permissions on the ”/etc/passwd” file are restricted.
Assess configuration problems and file permissions to evaluate the risk of a security incident caused by an administrator’s mistake or error (a regular user obtaining privileges, or obtaining /root privileges).

Verification

Check the access permissions of the “/etc/passwd” file. The result is satisfactory if the file is owned by root and its permissions are “644(rw-r–r–)”.

■ Command

# ls –al /etc/passwd

Configuration

Set the permissions of the /etc/passwd file to “644” with root as the owner.

■ Command

# chmod 644 /etc/passwd
# chown root /etc/passwd

1.4. group File Permission Settings (Importance: High)

Overview

If a regular user can access and tamper with the group file, an unauthorized user can be registered in the root group and obtain root privileges. Check that regular users cannot modify the group file, and restrict write permission for other users.

Verification

Check the access permissions of the “/etc/group” file. The result is satisfactory if the file is owned by root and its permissions are “644(rw-r–r–)”.

■ Command

# ls –al /etc/group

Configuration

Set the permissions of the /etc/group file to “644” with root (or bin) as the owner.

■ Command

# chmod 644 /etc/group
# chown root /etc/group

1.5. Applying Password Usage Rules (Importance: Medium)

Overview

To avoid password-guessing attacks, check whether a minimum password length is configured.
If a minimum password length is not configured, or is set too short, a weak password may be used and a malicious user can guess it easily.

Minimum password length
- To avoid password-guessing attacks, check whether a minimum password length is configured.
- If a minimum password length is not configured, or is set too short, a weak password may be used and a malicious user can guess it easily.
Maximum password lifetime
- If a password is disclosed through any path, check the password age limit so that a user who connected without authorization cannot keep reconnecting indefinitely.
Minimum password lifetime
- Configure the system so that, after a password is changed, it cannot be changed again within the minimum lifetime.

Verification

A. Password usage rules

The result is satisfactory if the password length is at least 8 characters, the maximum lifetime is 70 days (10 weeks) or less, and the minimum lifetime is 7 days (1 week) or more. (Rules may differ by organization.)

■ Command

# cat /etc/login.defs | grep -i "PASS_MAX_DAYS"
# cat /etc/login.defs | grep -i "PASS_MIN_DAYS"
# cat /etc/login.defs | grep -i "PASS_MIN_LEN"

B. Password settings

At least 8 characters, combining two or more of letters, numbers, and special characters

Configuration

1. How to apply the password usage rules

A password length of at least 8 characters is recommended.
A maximum password lifetime of 70 days (10 weeks) or less is recommended.
A minimum password lifetime of 7 days (1 week) or more is recommended.

■ Command

Run #vi /etc/login.defs and change the settings as follows (unit: weeks)
#vi /etc/login.defs
  PASS_MIN_LEN 8
  PASS_MAX_DAYS 70
  PASS_MIN_DAYS 7

2. Password configuration criteria
1) Construct a password from at least two of the four character types below, with a length of at least 10 characters, or from at least three types, with a length of at least 8 characters
(1) Uppercase letters (26), lowercase letters (26), digits (10), and special characters (32)

2) Design the password to reflect the following so that an unauthorized person cannot easily guess it
(1) Do not use a null password
(2) Do not compose it of letters only or of digits only
(3) Do not use a password that is identical or similar to the user ID
(4) Do not use consecutive letters or numbers (for example, 1111, 1234, abcd)
(5) Do not reuse passwords on a periodic cycle
(6) Do not use easily guessed personal information, such as a phone number or birthday, as a password

3) The LANMan algorithm used to store passwords in the SAM file encrypts characters in 8-character units, so a password whose length is a multiple of 8 is recommended (an 8-character password is recommended)

4) Avoid setting passwords such as the following
Null, a string identical or similar to the account name, a region name, a department name, a staff member’s name, or a primary business-function name
“root”, “rootroot”, “root123”, “123root”, “admin”, “admin123”, “123admin”, “osadmin”, “adminos”

■ Command

# passwd [account name]

1.6. Shell Restriction for Accounts That Do Not Need to Log In (Importance: Medium)

Overview

Restricting the shell for users who rarely need access prevents unauthorized system use and reduces the possibility of compromise.

Verification

For system accounts that do not need to log in, restrict execution shells such as ‘/bin/sh’, and assign a ‘nologin’ (/bin/false) shell to prohibit login

< Accounts that do not require an execution shell * For accounts that do not need to log in, assign “nologin”>
[System accounts such as daemon, bin, sys, adm, listen, nobody, nobody4, noaccess, diag, listen, operator, games, and gopher, generally those with a uid of 100 or lower or of 60000 or higher]

The following is a sample of the /etc/passwd file. Fields are separated by “:“. If the last field is “nologin”(or /bin/false), a non-functional shell has been applied to the account.

① : Indicates the user account. 
② : Indicates that the password is encrypted and stored in the shadow file. 
③ : The user number. It is 0 because this is the administrator. For a regular user, numbering starts at 500. 
④ : The group ID. It is 0 because this is the administrator group. 
⑤ : The real name. This setting has no particular effect on the system configuration. You may enter your own name. 
⑥ : Sets the user’s home directory. Because this is the administrator, the home directory is /root. 
⑦ : Defines the user’s shell.

< Account settings when a shell login is not required >
■ Command

Run #vi /etc/login.defs and change the settings as follows (unit: weeks)
# useradd account -c "account finger information" -d /home/{account} -m -s /bin/false

Configuration

■ Command

Run #vi /etc/passwd and change the settings as follows (unit: weeks)
  Example) Configure the daemon account so that it cannot log in
# vi /etc/passwd 
  daemon:x:1:1::/:/sbin/ksh (before change)
  daemon:x:1:1::/:/bin/false (after change)

1.7. Restricting Use of SU (Select User) (Importance: Medium)

Overview

An unprivileged regular user can obtain root privileges through password guessing with the su command.

Verification

The result is satisfactory if the auth required pam_wheel.so use_uid line in the /etc/pam.d/su file is not commented out (#) and accounts in the wheel group in the /etc/group file are restricted
Example of a vulnerable /etc/pam.d/su setting: a comment (#)

■ Command

# cat /etc/pam.d/su | grep -v 'trust' | grep 'pam_wheel.so' | grep 'use_uid'

Configuration

Restrict use of the su command by regular users. (When only the wheel group is allowed to use the su command)

1. Configure the /etc/pam.d/su file as follows.
auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_wheel.so debug group=wheel

2. Create the wheel group
# groupadd wheel
3. In the /etc/group file, add users who will use the su command to the wheel group.
# usermod –G wheel username
■ Command

# vi /etc/pam.d/su (remove the comment)
  auth       sufficient   /lib/security/pam_rootok.so
  auth       required   /lib/security/pam_wheel.so debug group=wheel
# groupadd wheel 
# usermod –G wheel username

2. File System

2.1. User UMASK (User Mask) Settings (Importance: Low)

Overview

The access permissions of a file newly created by a user on the system depend on UMASK.
To view the UMASK set for the current user, run “umask” at the command prompt. A UMASK value of “022” is recommended.
A UMASK value of “022” creates files with “rw-r–r–” access permissions.

Verification

The result is satisfactory if the current system UMASK is “022” or “027” and UMASK is set in the account’s start profile

■ Command

# umask
# cat /etc/profile | grep -i "umask"

Configuration

The UMASK value must be changed to “022”.
If the command is added to the account’s start profile (/etc/profile, /etc/default/login, .cshrc, .kshrc, .bashrc, .login, .profile, and so on), the changed UMASK value still applies after the user logs in.

■ Command

# umask 022
# vi /etc/profile
  Add the line umask 022

2.2. SUID (Set User-Id), (Set Group-Id) Settings (Importance: Low)

Overview

Files with SUID (Set User-ID) or SGID (Set Group-ID) set, especially files owned by root, are frequently used in buffer overflow attacks and local attacks and require strict security management. These files need to be managed periodically.
For root-owned setuid files that are weak from a security standpoint, remove the setuid and setgid attributes from setuid and setgid files other than those that are strictly required, and periodically assess and manage whether they are misconfigured and pose a security threat.
1. Remove them by referring to the list of Setuid and Setgid files whose settings should be removed. (See the table below.)
  In addition to the list below, Setuid must also be removed when an unusual file is found, including a file created by an application or a file created arbitrarily by a user.
  When removing Setuid, proceed carefully while checking that the OS and applications and other services still operate normally.
2. If a Setuid file must be used, restrict it so that only a specific group can use it.

[Table 1. List of Unnecessary Setuid and Setgid Files]

XenServer
/sbin/dump	/usr/bin/lpq-lpd	/usr/bin/newgrp
/sbin/restore	/usr/bin/lpr	/usr/sbin/lpc
/sbin/unix_chkpwd	/usr/bin/lpr-lpd	/usr/sbin/lpc-lpd
/usr/bin/at	/usr/bin/lprm	/usr/sbin/traceroute
/usr/bin/lpq	/usr/bin/lprm-lpd

[Table 2. Citrix XenServer 5.6.0 Default Setuid and Setgid List]

Application	Path	Type
userhelper	/usr/sbin/userhelper	Setuid
usernetctl	/usr/sbin/ usernetctl	Setuid
Ping6	/bin/ping6	Setuid
su	/bin/su	Setuid
umount	/bin/ umount	Setuid
Pam_timestamp_check	/sbin/ Pam_timestamp_check	Setuid
mount.ecryptfs_private	/sbin/ mount.ecryptfs_private	Setuid
mount.nfs	/sbin/ mount.nfs	Setuid
mount.nfs4	/sbin/ mount.nfs4	Setuid
unix_chkpwd	/sbin/ unix_chkpwd	Setuid
Citrix Directory	/opt/*

Verification

Setuid and Setgid must be audited periodically.

■ Command

# find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -lg {} \;

Configuration

1. Referring to [Table 1. List of Unnecessary Setuid and Setgid Files], remove Setuid and Setgid
■ Command

# chmod –s [file name]

2. Use must be restricted to a specific group.:
Example) Restrict Setuid use by regular users (only an arbitrary group is allowed)
■ Command

# /usr/bin/chgrp <Group_Name> <Setuid_File_Name>
# /usr/bin/chmod 4750 <Setuid_File_Name>

If the wiki account, which should be allowed to use Setuid, is to be placed in an arbitrary group, do the following.

■ Command

# usermod –G100 wiki
G : Change the supplementary group list setting
100 : the numerical value of the <Group>’s ID

2.3. xsconsole File Permission Settings (Importance: High)

Overview

Check whether access permissions on the xsconsole file are restricted.
xsconsole runs the XenServcer Configuration program.
If the access permissions of xsconsole are configured incorrectly, an unauthorized attacker can change the settings.

Verification

The result is satisfactory if the ”/usr/bin/xsconsole” file is owned by root and other users do not have write permission.

■ Command

# ls –alL /usr/bin/xsconsole

Configuration

On the xsconsole file, remove write permission for users other than the root owner.

※ If the file is a link, change ownership of the linked original file

■ Command

# chown root /usr/bin/xsconsole
# chmod o-w /usr/bi
/xsconsole

2.4. Crontab File Permission Settings and Management (Importance: Low)

Overview

Check whether regular users are restricted from malicious access to cron-related files.
Cron is a program that provides job scheduling and automatically runs a specific task at a specific time.
If the access permissions of cron-related files are configured incorrectly, an unauthorized person can change the user environment in various ways and cause a security incident.

Verification

A. Crontab configuration file permissions
/etc/crontab, /etc/cron.daily/*, /etc/cron.hourly/*, /etc/cron.monthly/*, /etc/cron.weekly/*,
The result is satisfactory if other users do not have write permission on /var/spool/cron/*.

B. Permissions of files scheduled for execution by Crontab
For executable files configured to run from Crontab with root privileges, confirm that the permissions are 744 and the owner is root

Configuration

1. Remediation for the Crontab configuration file

/etc/crontab, /etc/cron.daily/*, /etc/cron.hourly/*, /etc/cron.monthly/*, /etc/cron.weekly/*,

If other users have been granted write permission on /var/spool/cron/*, remove it
■ Command

# chmod o-w /etc/crontab 
# chmod o-w /etc/cron.daily/*
# chmod o-w /etc/cron.hourly/*
# chmod o-w /etc/cron.monthly/*
# chmod o-w /etc/cron.weekly/*
# chmod o-w /var/spool/cron/*

2. Remediation for files scheduled for execution by Crontab

Check the permissions of each file, then change them

■ Command

# crontab –ㅣ
  1 15 * * /backup/OS_backup.sh
  30    *    *    *    *    /opt/sfm/vacuum
  
# ls –al [file]
# chmod 744 [file]
# ls -al /backup/OS_backup.sh
  -rwxr--r-  *   1 root       sys             84 Aug 10 05:01 /backup/OS_backup.sh
# ls -al /opt/sfm/vacuum
  -rwxr--r-  *   1 root       sys             67 Dec 18 14:47 /opt/sfm/vacuum

2.5. /etc/profile File Permission Settings (Importance: Medium)

Overview

Check whether access permissions on /etc/profile, the user configuration file, are restricted.
The /etc/profile file is the login script that sets the default environment for every user who logs in.
If the access permissions of /etc/profile are configured incorrectly, an unauthorized person can change the user environment in various ways and cause a security incident.

Verification

The result is satisfactory if the /etc/profile file is owned by root (or bin) and other users do not have write permission.

■ Command

# ls –al /etc/profile

Configuration

Remove write permission for other users on the /etc/profile file owned by root (or bin)

■ Command

# chown root /etc/profile 
# chmod o-w/tcprofle

2.6. /etc/hosts File Permission Settings (Importance: Medium)

Overview

Check whether access permissions on /etc/hosts, the hostname registration file, are restricted.
The /etc/hosts file is used to map an IP address to a host name. If its access permissions are configured incorrectly, a malicious system will be trusted.

Verification

The result is satisfactory if the /etc/hosts file is owned by root (or bin) and other users do not have write permission.

■ Command

# ls –al /etc/hosts

Configuration

Remove write permission for other users on the /etc/hosts file owned by root (or bin)

■ Command
※ If the file is a link, change ownership of the linked original file

# chown root /etc/hosts 
  hmd o- /etc/hosts

2.7. /etc/issue File Permission Settings (Importance: Medium)

Overview

Check whether access permissions on /etc/issue, which is related to terminal settings, are restricted.

Verification

The result is satisfactory if the /etc/issue file is owned by root (or bin) and other users do not have write permission.

■ Command

# ls –al /etc/issue

Configuration

Remove write permission for other users on the /etc/issue file owned by root (or bin)

■ Command
※ If the file is a link, change ownership of the linked original file

# chown root /etc/issue 
# chmod o-w /etc/issue

2.8. User Home Directory and File Management (Importance: Low)

Overview

If an unauthorized user accesses files in a user’s home directory and tampers with configuration files and other files, the legitimate user’s service is restricted. Check that regular users other than the account that owns the home directory cannot modify that home directory.

Verification

A. The result is satisfactory if other users do not have write permission on each user’s home directory.

■ Command

# ls -dal /etc/issue

B. The result is satisfactory if other users do not have write permission on environment-variable files such as “.profile”, “.kshrc”, “.cshrc”, “.bashrc”, “.bash_profile”, “.login”, “.exrc”, “.netrc”, “.dtprofile”, and “.Xdefaults”.

■ Command

# ls –al [file name] 
# ls –ldb [file name] 
Ex) ls –ldb /root/.cshrc  ro/.bsh profile  /root/.bash_profie

Configuration

Remove write permission for other users on each user’s home directory

■ Command

# chmod o-w [home directory]

Remove write permission for other users on environment-variable files such as “.profile”, “.kshrc”, “.cshrc”, “.bashrc”, “.bash_profile”, “.login”, “.exrc”, “.netrc”, “.dtprofile”, and “.Xdefaults”

■ Command

# chmod o-w [file name]
# chmod o-w [home directory path] [file name]  (when removing permissions from a home-directory configuration file)

2.9. Permission Settings for Major Directories (Importance: Medium)

Overview

Check whether file permissions on major directories are set appropriately.
If access permissions on major directories are configured incorrectly, an unauthorized person can change the user environment in various ways and cause a security incident.

Verification

The result is satisfactory if the “/usr/bin/xsconsole, /usr/lib/xsconsole, /opt, /sbin, /etc, /bin, /usr/bin, /usr/sbin directories are owned by root (or bin) and other users do not have write permission.

■ Command

#ls -ldb /usr/bin/xsconsole /usr/lib/xsconsole /opt /sbin /etc/ /bin /usr/bin /usr/sbin

Configuration

Remove write permission for other users on the /usr/bin/xsconsole, /usr/lib/xsconsole, /opt, /sbin, /etc/, /bin, /usr/bin, and /usr/sbin directories owned by root (or bin).

■ Command

# chown root [directory name]
# chmod o-w [directory name]

2.10. PATH Environment Variable Settings (Importance: Medium)

Overview

If the PATH environment variable of the root account includes ”.“ (which refers to the current directory), a command located in the current directory can be executed unintentionally by an authorized user of the root account. That is, if ”.“ is placed ahead of directories that contain commands, such as /usr/bin, /bin, and /sbin, then when an authorized user of the root account runs any command, a file that an unauthorized person has illegally placed there can be executed unintentionally and produce an unexpected result.

Not only ”.“ but also pointing first at a directory that an unauthorized person created illegally can produce an unexpected result.

Verification

Check with echo $PATH (this applies to the root account only). It is vulnerable if ”.“ , which represents the current directory, is placed at the beginning or in the middle.

■ Command

# echo $PATH

Configuration

In the root account’s environment-variable configuration files (.profile, .cshrc, and so on) and in ”/etc/profile“ and similar files, please remove ”.“, which represents the current directory, from the PATH environment variable.
( ”.“, which means the current directory, must not be at the beginning or in the middle of PATH → move it to the end or remove it)

If the application configuration requires that ”.“ be used, move ”.“ to the end of the PATH environment variable.

2.11. /etc/service File Permission Settings (Importance: Medium)

Overview

If regular users who are not administrators can access and change the service file, they can restrict a legitimate service or run a service that is not allowed, creating a risk of a security incident.

Verification

The result is satisfactory if the service file is owned by root (or bin) and other users do not have write permission.

■ Command

# ls -alL  /etc/services

Configuration

Remove write permission for other users on the service file owned by root (or bin)

■ Command

# chown root w /etc/services
# chmod o-w /etc/services

2.12. Boot Script File Permission Settings (Importance: High)

Overview

Check whether access permissions are restricted on other important files used by the OS.
Access permissions on files that are important to system operation must allow access only by users who truly need it.
For the other important files below, remove write permission for other users if it has been granted.

[Table 1. Other Important Files]

/opt//	/etc/rc.d/	/etc/inittab	/etc/syslog.conf
/etc/snmp/snmpd.conf	/etc/crontab	/etc/cron.daily/*	/etc/cron.hourly/*
/etc/cron.monthly/*	/etc/cron.weekly/*	/var/spool/cron/*

and so on

Verification

Referring to [Table 1. Other Important Files], the result is satisfactory if a file is owned by root (or bin) and other users do not have write permission.

■ Command

# ls -alL /opt/*/*

Configuration

Referring to [Table 1. Other Important Files], remediate any file name found to be vulnerable by using the command below.

■ Command

# chmod o-w [file name or directory name]

3. Network Services and Major Application Settings

3.1. Service Banner Management (Importance: Medium)

Overview

Manage the banner displayed when a common service (SSH, SFTP, and so on) is accessed on the system, so that the service version is not disclosed.
State who is permitted to use the server, and indicate that all activity is monitored.
Configure the banner so that the version of the process and the system host name are not exposed.

※ The banner file location may differ depending on the sshd_config settings.

Verification

The result is satisfactory if a banner is configured in the ”/etc/ssh/sshd_config“ file

■ Command

# cat  /etc/ssh/sshd_config  |  grep  "Banner"

The result is satisfactory if the configured banner is displayed when connecting with SSH

The result is satisfactory if the configured banner is displayed when connecting with SFTP

Configuration

Configure a banner that is displayed on access through SSH or SFTP so that the process version and the system host name are not exposed

Step 1. In the ”/etc/ssh/sshd_config“ file, configure the banner file ■ Command

# vi /etc/sshd/sshd_config
  Banner  /etc/issue.net

Step 2. Create the ”/etc/issue.net file and insert a warning message (example)

#####################################################################################
#       This system is for the use of authorized users only.                        #
#       Individuals using this computer system without authority, or in             #
#       excess of their authority, are subject to having all of their               #
#       activities on this system monitored and recorded by system                  #
#       personnel.                                                                  #
#                                                                                   #
#       In the course of monitoring individuals improperly using this               #
#       system, or in the course of system maintenance, the activities              #
#       of authorized users may also be monitored.                                  #
#                                                                                   #
#       Anyone using this system expressly consents to such monitoring              #
#       and is advised that if such monitoring reveals possible                     #
#       evidence of criminal activity, system personnel may provide the             #
#       evidence of such monitoring to law enforcement officials.                   #
#####################################################################################

3.2. Session Timeout Settings (Importance: Low)

Overview

Check whether a connected session is configured to be disconnected by the server when it is unused for a specified time.
If a timeout is not set for an unused session, problems can arise for confidentiality as well as for availability.
A connected session needs to be configured so that the server disconnects it when it is unused for a specified time. (Timeout after 300 seconds)

Verification

The result is “satisfactory” if a timeout is configured in both “/etc/profile” and “xsconsole”

1. Check whether a session timoeout is configured in the “/etc/profile” file.

■ Command

# cat  /etc/profile  |  grep  "TMOUT"

2. Check whether Auto–Logout Time is configured in xsconsole.

■ Command

# xsconsole

Configuration

1. Edit the “/etc/profile” file and add the following (remove the comment or insert it as new)

■ Command

# vi /etc/profile 
  TMOUT=300
  export TMOUT

2. When configuring it in xsconsole
Step1. In the [Authentication] menu, select the “Change Auto-Logout Time” menu, then log in

■ Command

# xsconsole

Step2. On the [Change Auto-Logout Timeout] screen that appears after login, set “Timeout”.

3.3. Restricting SSH and SFTP Access for the root Account (Importance: High)

Overview

Direct remote access as root is a security risk, so, for security, root should be reached through a regular user by using the su command.

This is necessary for security so that it is known which account was used to reach root (the superuser).

Verification

The result is satisfactory if the “/etc/pam.d/login” file and the “/etc/ssh/sshd_config” file are configured as follows

1) /etc/pam.d/login
auth required pam_securetty.so
Or, auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
Or, auth required /lib/security/pam_securetty.so
2) /etc/ssh/sshd_config
PermitRootLogin no

■ Command

# cat  /etc/pam.d/login | grep  "pam_securetty.so"
# cat  /etc/ssh/sshd_config | grep  "PermitRootLogin"

Configuration

Restrict direct access as root through the settings in the “/etc/pam.d/login” file and the “/etc/ssh/sshd_config” file

■ Command 1) Edit the “/etc/pam.d/login” file (remove the comment or insert it as new)

# vi /etc/pam.d/login
  auth  required  /lib/security/pam_securetty.so

2) Also edit the “/etc/ssh/sshd_config” file (remove the comment or insert it as new)

# vi /etc/ssh/sshd_config
  PermitRootLogin  no

3.4. SSH (Secure Shell) Version Vulnerabilities (Importance: Medium)

Overview

OpenSSH is an open-source program that implements the SSH (Secure Shell) protocol and replaces telnet, ftp, rlogin, rsh, and similar services.
OpenSSH encrypts network traffic and can protect important data from attacks such as packet sniffing. However, many vulnerabilities have been found in older versions of OpenSSH, and those vulnerabilities can make the system a target of various attacks, including obtaining root privileges and DoS attacks.
Citrix uses SSH as the protocol for accessing the Xenserver server.

Verification

Check the SSH version. It is vulnerable if it is at or below OpenSSH 4.3p2, the version cited for the Xenserver 5.6.0 server

■ Command

# ssh -V

Configuration

1. When the service is required
On the Xenserver 5.6.0 server, using SSH version OpenSSH 4.3p2 or later is recommended.

2. When the service is not required
Step 1. Stop the service that is running
■ Command

# ps  -ef  |  grep  sshd
  root    414  0.0  0.7  2672 1692  /usr/sbin/sshd
# kill   * 9  414

Step 2. Rename the startup script file so that SSH does not start (the startup script location differs for each OS)
■ Command

# ls  -al  /etc/rc*.d/*  |  grep sshdz   (check the startup script file location)
# mv  /etc/rc2.d/S55sshd  /etc/rc2.d/_S55sshd 
※ The location of the /etc/ssh/sshd_config file may differ depending on the SSH settings

3.5. Removing Unnecessary Services (Importance: Low)

Overview

1. If the ports in [Table 1. Unnecessary Services] are open on the server, they can expose important system information and cause a denial of service (DOS). [Table 1. Unnecessary Services]

echo(7)	Simply retransmits a message sent by the client
chargen(19)	A service that returns a string of arbitrary length
finger(79)	Displays user information.
nntp(119)	NNTP (Network News Transfer Protocol), a standard service that can create discussion groups on the Internet
netbios_dgm(138)	NetBIOS Datagram service, used to broadcast to a host, a group, or everyone.
ldap(389)	A service for directory service access
ntalk(518)	A service that makes chat possible between different systems
ldaps(636)	LDAP over SSL
nfsd(2049) – when NFS is not in use	NFS server daemon service
discard(9)	A service that discards data received from any user
time(37)	The TCP version of the RFC 868 time server used by the rdate daemon
sftp(115)	ftp over SSH
ntp(123)	ntp (Network Time Protocol) synchronizes the time of the client and the server.
netbios_ssn(139)	NetBIOS session service, used to send and receive actual data through network shares and similar means.
printer(515)	Used to spool on a remote printer.
uucp(540)	Copies files between different Unix systems and sends commands to be executed on another system
ingreslock(1524)	Ingre database lock service
dtspcd(6112)	Desktop subprocess control daemon service
daytime(13)	daytime is a daemon that, in response to a client query, prints the current time and date in ASCII form.
tftp(69)	A protocol for file transfer. On an OS, the tftp protocol is used to download a configuration file and to start the installation process for a workstation that has no boot diskette, or for a network-aware printer.
uucp-path(117)	Uucp path service
netbios_ns(137)	NetBIOS name service, used to identify resources on the network.
bftp(152)	binary File Transfer Protocol
talk(517)	A user can connect to the system remotely and start a conversation session with a user who is logged in on another system.
pcserver(600)	ECD Integrated PC board srvr, used in RPC-related attacks.
www-ldap-gw(1760)	HTTP to LDAP gateway, used when LDAP sends database information to a web server

2. SSH and VNC are provided for server administration of cloud computing services that use Xenserver.

If services that are unnecessary for a cloud computing service, such as telnet, ftp, rlogin, and rsh, are used, vulnerabilities in each protocol can make the system a target of various attacks, including obtaining root privileges and DoS attacks.
Referring to [Table 2. Services Unnecessary for Cloud Computing], deletion of the corresponding services is recommended.

[Table 2. Services Unnecessary for Cloud Computing]

FTP	NFS	RPC	SNMP
Sendmail	SWAT	Samba	NIS, NIS+
telnet	RLOGIN	RSH	Other

Verification

1. Among the services in the “/etc/xinetd.d” directory, identify unused services from [Table 1. Unnecessary Services].

2. Referring to [Table 2. Services Unnecessary for Cloud Computing], the result is satisfactory if those services are not in use.
■ Command

# ps –ef  | grep [service name]

Configuration

A. When the service is required

When the service is used, consultation with the security officer and the responsible manager is required
Installing and operating the latest version of the service is recommended

B. When the service is not required
1. Please remove unused services listed in [Table 1. Unnecessary Services]
■ Command
Step 1. Edit the service file in the “/etc/xinetd.d” directory

# vi  /etc/xinetd.d/ [service file name]

Step2. In the “xinetd.d” directory, set Disable to yes for services that are not needed

/etc/xinetd.d/chargen file
service chargen
{
      Disable         = yes
      type            = INTERNAL
      id              = chargen-stream
      socket_type     = stream
      protocol        = tcp
      user            = root
      wait            = no
}

Step3. Restart the service

#service xinetd restart

2. Please remove [Table 2. Services Unnecessary for Cloud Computing], which are unnecessary for cloud computing services
■ Command

# ps  -ef  |  grep  [service name]
# kill   * 9  [process ID]

4. Hypervisor Policy Settings

4.1. Administrative Remote Access Control (Importance: High)

Overview

XenServer can be accessed remotely for administration by using SSH or XenCenter.

If an administrator does not need remote access to XenServer, restricting administrative remote access prevents unauthorized system use and reduces the possibility of compromise.

Verification

It is “vulnerable” if “Interface” is configured in the [Network and Management Interface] menu of xsconsole

※ Restricting administrative remote access requires consultation with the security officer and the responsible manager

■ Command

# xsconsole

Configuration

If remote access for administration is not required, configuring an access restriction is recommended.

Step 1. In the [Network and Management Interface] menu of xsconsole, select [Configure Management Interface], then log in

■ Command

# xsconsole

Step 2. On the [Management Interface Configuration] screen that appears after login, select “Disable Management Interface” to block remote access used for administration.

4.2. Remote Shell Access Control (Importance: High)

Overview

XenServer can be accessed remotely by using Remote Shell.
If access to XenServer is allowed only through XenCenter and access through Remote Shell is not required, restricting administrative remote access prevents unauthorized system use and reduces the possibility of compromise.

Verification

It is “vulnerable” if [Enable/Disable Remote Shell] is set to “Enable” in the [Remote Service Configuration] menu of Xsconsole

※ Restricting administrative remote access requires consultation with the security officer and the responsible manager

■ Command

# xsconsole

Configuration

If access to XenServer is to be allowed only through XenCenter, configuring a Remote Shell access restriction is recommended.

Step 1. In the [Remote Service Configuration] menu of xsconsole, select [Enable/Disable Remote Shell], then log in

■ Command

# xsconsole

Step 2. On the [Configure Remote Shell] screen that appears after login, select “Disable” to block remote shell access.

4.3. Guest VM Network Separation (Importance: High)

Overview

A guest network can separate traffic by using a VLAN.
If networks between Guest OS (Virtual Machine) groups are interconnected, sensitive traffic may be accessible.
A Guest OS (Virtual Machine) group that must be separated should be used with its traffic separated by VLAN.

Verification

1. When using XenCenter
Step 1. Check every network currently in use and identify the networks that are configured as VLANs.

Step 2. The result is “satisfactory” if an identified VLAN is configured on a Guest OS that requires network separation

Configuration

1. When using XenCenter
Step 1. In XenCenter, select [XenServer], then in the [Network] menu select [Add Network] under “Network”.

Step 2. On the network creation screen, select “External Network”, then select [Next].

Step 3. Enter the name and description of the VLAN to be created, then select [Next].

Step 4. Select the physical NIC on which to configure the VLAN, select the VLAN tag, then select [Finish] to create the VLAN. ※ A tag that is already in use cannot be configured.

Step 5. The created VLAN can be confirmed in Server Networks.

Step 6. Select the Guest OS that requires network separation, select [Network], then select [Add Interface].
※ The Guest OS must be shut down before the setting can be applied.

Step 7. Under “Network”, select the VLAN that was created, then select [Add] to set the Guest OS network to that VLAN.

Step 8. In Virtual Network Interfaces, the network configured on the Guest OS can be confirmed, including that it is currently set to the VLAN.

5. Log Management

5.1. su Log Settings (Importance: High)

Overview

A security setting is required so that su usage is logged, in order to record use that goes from a regular user to the superuser. When an incident occurs that compromises system availability, integrity, or a similar property, the incident generally proceeds with superuser privileges, so logging of su is required.
Modify the syslog configuration file so that su logs are recorded. If logs related to auth.notice are not being written to a file, configure them as follows.

Verification

The result is satisfactory if su records are present when /var/log/sulog or the /var/log/secure file is checked

■ Command

# cat /etc/login.defs | grep SULOG_FILE
# cat /etc/syslog.conf | grep authpriv.*

Configuration

Configure the system so that su records are left, as confirmed in /var/log/sulog or the /var/log/secure file

■ Command

Run # vi /etc/login.defs and change the settings as follows
  SULOG_FILE   /var/log/sulog     
or 
In the # vi /etc/syslog.conf file, change the settings as follows
  authpriv.* /var/log/secure

After applying the settings above, restart syslog

# /etc/rc.d/init.d/syslog restart

5.2. syslog Settings (Importance: High)

Overview

Check whether security settings have been applied to the “syslog.co” file so that records of info, alert, and similar events that occur during system operation are kept.
The syslog daemon is a dedicated daemon that records system logs and monitors kernel messages and system logs of remote or local systems.
If this setting is not correct, appropriate logs are not left in the system log file, and an intruder’s traces or system errors cannot be analyzed.

[Table. XenServer/XenCenter System Log Files]

XenServer log location
/val/log/ xensource.log
/var/log/ xenstored-access.log

Windwos7 log location
%userprofile%\AppData\Roaming\Citrix\XenCenter\logs\ XenCenter Audit Trail.log
%userprofile%\AppData\Roaming\Citrix\XenCenter\logs\ XenCenter.log

Windows XP / 2003 log location
%userprofile%\AppData\Citrix\XenCenter\logs\ XenCenter Audit Trail.log
%userprofile%\AppData\Citrix\XenCenter\logs\ XenCenter.log

Windows Vista log location
%userprofile%\AppData\Citrix\Roaming\XenCenter\logs\ XenCenter Audit Trail.log
%userprofile%\AppData\Citrix\Roaming\XenCenter\logs \ XenCenter.log

Verification

1. How to check XenServer log files

(1) Inspect the “etc/syslog.conf” file and check the log file settings for info, alert, and similar events

■ Command

# cat /etc/syslog.conf | egrep "info|alert|notice|debug" | egrep "var|log"

(2) Inspect the “/etc/xensource/log.conf” file and check the log file settings for info, alert, and similar events

■ Command

# cat /etc/xensource/log.conf | egrep "info|warn|error"

2. How to check XenCenter log files
Step1. In XenCenter, select [XenServer], then the logs can be checked in the [Logs] menu.

Step2. In the XenCenter menu, select [Help], then the logs can be checked in the [View Application Log files] menu.

Configuration

1. How to configure XenServer log files

(1) Inspect the “etc/syslog.conf” file and configure the log files for info, alert, and similar events
■ Command

# vi /etc/syslog.conf 
  *.notice     /var/log/messages
  *.emerg      *
  *.alert      /dev/console

(2) Inspect the “/etc/xensource/log.conf” file and configure the log files for info, warn, error, and similar events
■ Command

# vi /etc/xensorce/log.conf 
# Set info,warn,error to log to syslog by default
  info;audit;syslog:local6
  warn;;syslog:xapi
  error;;syslog:xapi

# Also print everything (debug<->error) into xensource.log for easier debugging
  debug;;file:/var/log/xensource.log
  info;;file:/var/log/xensource.log
  warn;;file:/var/log/xensource.log
  error;;file:/var/log/xensource.log

(3) After the “syslog.conf” and “log.conf” files are modified, restart syslogd with the following command so that the change is applied.

■ Command

# ps  -ef  | grep  syslogd
# kill  -HUP  7524(PS ID)

5.3. Blocking the syslog Transmission Port (Importance: High)

Overview

UDP port 514 is used as the port that transmits syslog to a remote host. Using it is a security weakness, and if the service port is open there is a risk of a security incident.
If a remote log server is not used, blocking the syslog transmission port is recommended.

Verification

It is vulnerable if a remote log server is not used and UDP port 514 is in use

■ Command

# netstat –an | grep "udp" 
or
# netstat –an | grep "udp" | egrep "514"

Configuration

If a remote log server is not used, block UDP port 514.

1. When a remote log server is required
When a remote log is used, consultation with the security officer and the responsible manager is required

2. When a remote log server is not required
Step 1. Edit the syslog.conf file
Delete the “-r” option of “SYSLOGD_OPTIONS” in the “/etc/sysconfig/syslog” file

■ Command

# vi /etc/sysconfig/syslog
  SYSLOGD_OPTIONS="-m 0"

5.4. Logging Level Settings (Importance: Low)

Overview

Check whether log settings have been applied so that records of information and similar events that occur during system operation are kept.
If the system does not have an appropriate log file, an intruder’s traces or system errors cannot be analyzed.

Verification

1. When checking on XenServer

The result is “satisfactory” if “info” is configured in the “/etc/xensource/log.conf” file

■ Command

# cat /etc/xensource/log.conf | grep "info"

2. When checking in XenCenter

The result is “satisfactory” if the “Information” log is configured in the [Logs] menu after [XenServer] is selected in XenCenter

Configuration

1. When checking on XenServer

Configure the “/etc/xensource/log.conf” file so that “info” logs are recorded.

■ Command

# vi /etc/xensource/log.conf 
  info;;file:/var/log/xensource.log

2. When checking in XenCenter

In XenCenter, select [XenServer], then configure the [Logs] menu so that “Information” logs are recorded.

5.5. Log File Permission Settings (Importance: Low)

Overview

1. The system’s basic logging records do not need to be readable by regular users other than the administrator, so security should be strengthened by restricting the owner of, and the read permission on, the files that store logging records.

2. For the log file permissions below, remove write permission for other users on files owned by a system user (root, adm, bin, and so on).

[Table 1. Log Files Subject to Security Hardening]

Log file	XenServer	Log file	XenServer
xensource	/var/xensource.log	btmp	/var/log/btmp
xenstored	/var/xenstored-access.log	secure	/var/log/secure
wtmp	/var/log/wtmp	messages	/var/log/messages
lastlog	/var/log/lastlog	audit	/var/log/audit.log

Verification

Referring to [Table 1. Log Files Subject to Security Hardening], the result is satisfactory if the log file is owned by root and other users do not have write permission

■ Command

# ls –alL [log file name]

Configuration

Referring to [Table 1. Log Files Subject to Security Hardening], remove write permission for other users on the log file owned by root

■ Command

# chown  root  [log file name]
# chmod  o-w  [log file name]

To change the permissions with which the /var/adm/message file is created, edit the /usr/lib/newsyslog file

■ Command

#vi /usr/lib/newsyslog
  chmod  644    $LOG (before change)
  chmod  640    $LOG (after change)

6. Security Patches

6.1. Applying Security Patches (Importance: High)

Overview

A XenServer and XenCenter patch is an update file, released by Citrix after the Xen system, that corrects errors and security vulnerabilities in Xen-related applications, services, executables, and similar components.
An attack tool that exploits the vulnerability can appear soon after an update patch is announced, so it is recommended to install the update patch as soon as possible after it is announced.

Verification

Check the security patches announced by Citrix, and check the updates for the XenServer and XenCenter currently in use

Satisfactory: The latest update patch (Version: Citrix XenCenter 5.6 fp1) is installed
Vulnerable: The latest update patch (Version: Citrix XenCenter 5.6 fp1) is not installed
In the XenCenter menu, select [Help], then select [Check for Updates] to check for updates.

How to Apply

Install the latest update patch on the XenServer and XenCenter currently in use.

Step 1. Check for the latest updates by using the XenCenter update manager.

Step 2. Among the announced updates, find the security-related update for what is currently in use

Step 3. Download that update

Step 4. Install the update

6.2. Applying Guest OS Security Patches (Importance: High)

Overview

It is recommended that security patches and update patches be applied to the OS and software installed on the Guest OS(VM) before they are distributed.
An attack tool that exploits the vulnerability can appear soon after an update patch is announced, so it is recommended, as soon as possible after the announcement, to create an OS image (*.iso) file and apply it to XenServer.
Where possible, it is recommended to manage the OS and software configuration through OS and patch management tools (VMware Update Manager, Hyper-V SCVMM, and so on), check configuration management of the software included in the Guest OS(VM), and configure it so that updates can be applied automatically.

[Table 1. Supported OS and software on XenServer]

Operating systems supported for updates	Applications supported for updates
Microsoft Windows family	• Internet Information Server (IIS)
• Windows XP Professional, 32 bit, SP2 Required	• Windows Media Player, version 7.0 or later
• Windows XP Professional 64 bit	• Microsoft SQL Server versions 7.0/2000/2005
• Windows 2003 Datacenter	• Microsoft SQL Server Desktop Edition (MSDE) version 1.0 or later
• Windows 2000 Server, SP4 with Update Rollup 1	• Exchange 2000 Server and Exchange Server 5.0
• Windows 2000 Professional, SP4 Required	• Internet Explorer version 4.0 or later
• Windows Server 2003, SP1 Required	• Outlook Express version 4.01 or later
• Windows Server 2003 R2	• Microsoft Site Server 3.0
• Windows Server 2003 x64	• ISA Server 2000
• Windows Server 2003 Standard/Web, 32-bit and 64-bit	• Microsoft .NET Framework, version 1.0 or later
• Windows Server 2008	• Microsoft Data Access Components (MDAC) 2.5 or later
• Windows Vista Business	• BizTalk Server 2000 or later
• Windows Vista Enterprise	• SNA Server 4.0
• Windows Vista Business (x64)	• Host Integration Server 2000
• Windows Vista Enterprise (x64)	• WinZip 8.1 or later
Red Hat Linux family	• Apache 1.3 and 2.0
• Red Hat Enterprise Linux AS 3.0 (Update 5 Required)	• Firefox 1.0 or later
• Red Hat Enterprise Linux ES 3.0 (Update 5 Required)	• RealPlayer 10 or later
• Red Hat Enterprise Linux AS 4.0 (Update 2 Required)	• Adobe Acrobat Reader
• Red Hat Enterprise Linux ES 4.0 (Update 2 Required)

Verification

Check the security patches announced by each OS and software vendor, and check security-related updates for the OS and software currently in use

<Criteria for applying the latest security patch>
Satisfactory – The latest update patch is installed
Vulnerable – The latest update patch is not installed

Configuration

1. Before distributing the OS and software to the Guest OS

Upload an OS image with the latest security patches applied (extension *.iso) to the “/opt/xensource/packages/iso/” path, and, when creating a Guest OS , it is recommended to install an OS and software that have the latest security patches applied.

2. After distributing the OS and software to the Guest OS

Apply the latest security-related OS and software updates to the Guest OS currently in use.

Step 1. Find the corresponding version on the following site

<For the Windows family>
http://www.microsoft.com/korea/technet/security/current.asp
http://windowsupdate.microsoft.com/?IE

<For the Red Hat family>
http://www.redhat.com/security/updates/
http://www.redhat.com/security/updates/eol/ (Red Hat Linux 9 or earlier)

<For an application>
Check the latest patch information on each vendor’s site.

Step 2. Among the announced updates, find the security-related update for what is currently in use

Step 3. Download that update

Step 4. Install the update

※ If OS and patch management tools (VMware Update Manager, Hyper-V SCVMM, and so on) are used, an update can be applied automatically through a version check.