ESX 3.5/4.x ONLY - You need to enable remote SSH access.

Follow the steps in the recipe to enable SSH. However, note that leaving direct root SSH disabled is the suggested configuration.

SSH is a valuable service to have on your service console because it provides a way for an administrator to go behind the VMware GUI and issue commands directly to the OS running on the server. By default, ESXi does not have SSH enabled; in fact, VMware does not directly support running SSH on an ESXI server. If you need to enable it, however, you can do so by following these steps:

Your SSH service is now enabled, and you can access your console by using your favorite SSH terminal program.

ESX 3.5/4.x ONLY - Though they are normally disallowed, you want to enable direct root logins on your ESX Server.

Edit the SSH configuration file to allow direct root logins.

By default, ESX 3.x servers are set to deny remote root logins. Depending on your environment and personal preference, however, you may wish to enable such logins on your ESX Server consoles.

To enable SSH on your ESX console, follow these steps:

Your SSHD daemon is now set to permit direct root logins. Bear in mind that you are doing this at your own risk; best practice suggests leaving direct root SSH capabilities turned off.

ESX 3.5/4.x ONLY - You need to be able to manage the accounts for each of your users.

You can set up users and groups using the console, according to your needs. ESXi users can use lockdown mode to help secure their user environments.

You’ll make use of two commands in this recipe: useradd and groupadd. You’ll use the useradd command to make modifications to the /etc/passwd and /etc/shadow files, which store user information such as the UID, GID, path, shell, and home directory. You’ll also use the groupadd command to modify the /etc/group file, which stores the users’ group information. To begin, log in to the ESX Server as root via SSH or the console.

For this example, we are going to assume that you need to set up two groups, a junior system administrator group and a senior system administrator group. We’ll use the groupadd command to create the two groups from the command line:

groupadd jradmin
groupadd sradmin

Once you’ve created the groups, you will notice that they are listed in the /etc/group file. Now we’ll add users to the groups by using the useradd command from the command line. The useradd command has many different options, but we will only use the -g option to set the group membership:

useradd -g jradmin rtroy
useradd -g sradmin mhelmke

We now have two users, one assigned to the jradmin group and one assigned to the sradmin group. By setting up groups, you allow yourself to limit the areas each user can access. For example, if you are using sudo, you can give the jradmin group a less complete set of options than the sradmin group.

Our example invokes a very simple useradd command to set group membership. Other options are available to further customize your users’ accounts and groups. Here is some detailed information on the useradd command:

Usage: useradd [options] LOGIN

Options:
  -b, --base-dir BASE_DIR    Base directory for the new user account
                home directory
  -c, --comment COMMENT      Set the GECOS field for the new user account
  -d, --home-dir HOME_DIR    Home directory for the new user account
  -D, --defaults             Print or save modified default useradd
                configuration
  -e, --expiredate EXPIRE_DATE  Set account expiration date to EXPIRE_DATE
  -f, --inactive INACTIVE    Set password inactive after expiration
                to INACTIVE
  -g, --gid GROUP            Force use GROUP for the new user account
  -G, --groups GROUPS        List of supplementary groups for the new
                user account
  -h, --help                 Display this help message and exit
  -k, --skel SKEL_DIR        Specify an alternative skel directory
  -K, --key KEY=VALUE        Overrides /etc/login.defs defaults
  -m, --create-home          Create home directory for the new user
                account
  -o, --nonunique           Allow create user with duplicate
                (nonunique) UID
  -p, --password PASSWORD    Use encrypted password for the new user
                account
  -r, --system               Create a system account
  -s, --shell SHELL          The login shell for the new user account
  -u, --uid UID              Force use the UID for the new user account

Similarly, here is an overview of the groupadd command:

Usage: groupadd [options] GROUP

Options:
  -f, --forceforce      Exit with success status if the specified
                group already exists
  -g, --gid GID         Use GID for the new group
  -h, --help            Display this help message and exit
  -K, --key KEY=VALUE   Overrides /etc/login.defs defaults
  -o, --nonunique      Allow create group with duplicate
               (nonunique) GID

Another important command is userdel, which allows you to remove a user from the system. You have the option of leaving her home directory intact, which will preserve any personal settings, scripts, or applications stored there.

The userdel command will remove entries from both the /etc/passwd and /etc/shadow files. However, if you are using sudo, the userdel command will not remove any entries from the sudoers file, so be sure to remove those as necessary.

To remove a user and simultaneously delete that user’s home directory, use the -r option, as shown here:

userdel -r rtroy

To remove the user, but leave his or her home directory intact, omit the -r option:

userdel rtroy

Removing a group can be accomplished by using the groupdel command:

groupdel jradmin

This command removes the jradmin group from the server, deleting its entries in the /etc/group and /etc/gshadow files.

These commands offer many advanced features that you can find out about through their --help options or manpages.

Recipe 6.6

ESX 3.5/4.x ONLY - You want to control which users can access your ESX Server via SSH.

Configure individual account permissions to allow or deny SSH access to specific users.

For security, it is generally better to create an individual account for each user and to avoid allowing multiple users to have access to the root account. This allows actions to be connected to the people performing them and is especially important for tracking problems in case an administrator “goes rogue.” However, this approach does mean that you have to figure out how to allow these individual accounts to access the server securely.

By using the configuration options built into your SSH server, you can allow specific users to access your ESX Server directly, via SSH. To accomplish this, edit the SSH configuration file, located at /etc/ssh/sshd_config. Look for the line that says AllowUsers. If this line is commented out with a #, remove the # sign. If you do not see a line containing this information, make a new line like the example that follows, making sure to change the usernames according to your needs. In this example entry, we allow tom, chris, bob, and any user whose username starts with the word sysadmin to have SSH access:

AllowUsers   tom     chris   bob    sysadmin*

Once you are satisfied, save the configuration (by pressing the :wq! keys in vi). At the command line, restart the sshd daemon to make your configuration changes take effect. To do this, enter either this command:

/etc/init.d/sshd restart

or this one:

service sshd restart

You can also deny specific users permission to access your ESX Server directly with SSH. To do this, look for a line in the /etc/ssh/sshd_config file that says DenyUsers. If it is commented out with a #, remove the # sign. If you do not see a line containing this information, make a new line similar to the one that follows, remembering to change the usernames according to your needs. In this example, we deny access to george, todd, tim, and any user whose username starts with b:

DenyUsers    george  todd    tim    b*

Keep in mind when using the * wildcard character that, in our example, a user named bob would be denied access even if he is listed in the AllowUsers line as follows (that is, the deny rules take precedence over the allow rules):

AllowUsers   tom     chris   bob    sysadmin*

Save the file and restart the daemon as before.

The users who have been denied will be barred from logging into the system via SSH, and any login attempts they make will show up in the /var/log/messages file.

ESX 3.5/4.x ONLY - You want to display a specific message to each of your users when they attempt to log in to the server.

Edit the sshd_config file from the command line to enable the message of the day (MOTD).

The MOTD allows you to display a note to users when they try to access your server via the console or SSH.

By default, the ESX Server is not set up to display the MOTD when users log in via SSH, so you need to change the sshd_config file to display it.

The first thing to do is navigate to your /etc/ssh directory and open the sshd_config file with your favorite editor, as we do here using vi:

vi /etc/ssh/sshd_config

Change the following variable to enable SSH to display the MOTD by removing the # from the beginning of the line:

#PrintMotd yes

Save the file and restart the sshd services by issuing the following command:

service sshd restart

Now that the changes to the SSH configuration are in place, you can edit your /etc/motd file to include any information you wish to display to your users when they log in. This file comes standard with most Linux distributions and can be edited with your favorite editor. By default, the file is empty.

ESX 3.5/4.x ONLY - You want to change the root password.

Use the passwd command.

Changing the root user’s password on the ESX Host requires to you be logged in either via SSH or via the console directly. You will need to be logged in as root or become the root user using sudo. You can then change the password by issuing the following command:

passwd

If you are changing the password as sudo use the following:

sudo -s

passwd

You will be asked to enter the current password, enter the new password, and then reenter the new password a second time to confirm that you have typed it correctly. The next time you log in, you will need to use the new password.

ESX 3.5/4.x ONLY - You lost or forgot your root password and you need to change it.

Log in as root via sudo and change the password, or edit the GRUB menu to boot in single-user mode.

Because VMware uses a modified version of Red Hat Linux, recovering the root password is easy. We’ll look at two different ways to recover the root password.

The first (and perhaps the easiest) method is by using sudo. If you have an account with full sudo permissions, you can become the root user this way and change the root password.

For the second option, you will need to use the service console or be connected to a kernel-based virtual machine (KVM). To begin, use the GRUB menu, which is the menu you are first displayed when your ESX Server is booting, to boot into single-user mode.

You will notice three options in the GRUB menu (Figure 6-1): VMware ESX Server, which boots your ESX Server normally; VMware ESX Server (debug mode), which turns on debugging options; and Service Console only (troubleshooting mode), which will drop you to the command line and not initiate any of the key services. There is also some descriptive text under the menu, giving you more advanced options to use within the GRUB menu.

Figure 6-1. Boot menu for VMware ESX Server, showing boot selection

To begin the process of recovering your root password, you need to have the gray bar highlight the VMware ESX Server option on the menu. Press the letter e to bring up a more advanced menu, from which you will make a simple change to the kernel boot string. There are four menu options here, and you will use the line that starts with kernel (Figure 6-2). Highlight this line and press e again to enter edit mode.

Figure 6-2. Advanced boot options

Once in edit mode, go to the end of the line and add the word single (Figure 6-3). This tells the server to boot into single-user mode, allowing you to change the root password. Press Enter to return to the previous menu. Highlight the line starting with kernel and press the b key to initiate the single-user boot mode.

Figure 6-3. Adding single-user mode to the boot line

The system will be booted into single-user mode, and you will be given a command prompt from which you can type the passwd command to change your root password.

When the password change is complete, issue the reboot command to reboot the server in its original mode. Once rebooted, you can log in with the new root password.

ESX 3.5/4.x ONLY - Remote users can log in as root via the console, and you wish to prevent this for greater security.

Edit the configuration to prevent direct root login, even from the console.

By default, remote users cannot log in to an ESX Server as root. However, they can log in as root on the console that is directly connected to the server. If you wish to lock down your ESX Servers even further, you can disable the ability to log in directly as root on that console. Users to whom you give root privileges can still become root through the sudo command, but you can use techniques discussed in Recipe 6.4 to restrict the commands they can execute. You cannot do this if they can log in directly as root.

In this example we will be modifying the /etc/securetty file. When this file exists but is empty, direct root console logins are disabled. Follow these steps to implement this security measure:

Once complete, verify that you can no longer log in to the console directly as the root user.

If you wish to revert your changes, simply copy the securetty_backup file to securetty using the following command:

cp /etc/securetty_backup securetty

If you try to log in from the console directly as the root user after restoring the securetty file, you should be able to do so.

For reference, your securetty file should contain lines such as the following, which list terminals and virtual terminals where root login is allowed:

console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11

ESX 3.5/4.x ONLY - The GRUB menu may be accessed during a reboot, and you wish to prevent knowledgeable users from changing the boot parameters and either damaging the server or accessing things they should not.

Require a password to access the GRUB boot menu.

Setting a password for the ESX Server’s GRUB boot menu ensures that your kernel boot parameters cannot be bypassed when the server is rebooting. For example, the parameters in the GRUB boot menu control to which hard drive and kernel your ESX Server boots. If these parameters are erroneously changed, your ESX Server may be unbootable.

To restrict access to this menu, you need to generate an encrypted password and put it in the /etc/grub.conf configuration file.

Start by logging into your ESX Server with root permissions. From the command line, run the grub command. Next, at the grub prompt, enter md5crypt. You will be prompted for a password one time. Once your password has been validated, you will see an md5 hash text; copy this, because you will need to enter it in the /etc/grub.conf file. When you have copied the md5 hash, exit the grub application by typing quit.

Now, edit this file with your favorite editor:

/etc/grub.conf

In order to set a password on your GRUB menu, you’ll need to add a new variable to this file. Look for something similar to this:

...
default=1
timeout=10

Add the following line after the line that lists the timeout variable (keep in mind that, depending on your configuration, your timeout value may be slightly different). Substitute the hash string you saved for hash_string:

password –-md5 hash_string

Save the file and exit. When you reboot your ESX Server, you will not be able to edit any of the boot options at the GRUB menu without first entering a password. By adding a GRUB password, you are removing the last trick, practically speaking, by which someone with physical access to the system can gain unauthorized access to your server. About the only other things the attacker could do are boot from a CD or damage the system physically.

ESX 3.5/4.x ONLY - Allowing USB drives to be directly connected and mounted to your ESX Server may cause a security risk.

Disable the automatic mounting of USB devices on your ESX Server by editing the /etc/modules.conf file.

To get started, log in to your ESX Server as root. Then, edit the following file:

/etc/modules.conf

Search for the following entry and add a # sign at the beginning of the line:

alias usb-controller

After making the change, save the configuration file. You will need to reboot your server in order for the new settings to take effect.

Although the vCenter has an option called Security Profile that can help you maintain a large number of preset firewalls, you may encounter situations where you will need to maintain a custom rule specific to an application you wish to run.

ESX has a great tool called esxcli network firewall that allows you to maintain your firewall from the command line.

Before we get started, let’s take a look at some of the configuration options the esxcli network firewall command offers:

~ # esxcli network firewall
Usage: esxcli network firewall {cmd} [cmd options]

Available Namespaces:
  ruleset               Commands to list and update firewall ruleset configuration

Available Commands:
  get                   Get the firewall status.
  load                  Load firewall module and rulesets configuration.
  refresh               Load ruleset configuration for firewall.
  set                   Set firewall enabled status and default action.
  unload                Allow unload firewall module.

ESXi 5.x includes a new client interface to manage the firewall. Table 6-1 summarizes the commands available:

To view the current firewall ruleset and see which services are enabled or disabled:

~ # esxcli network firewall ruleset list
Name                Enabled
------------------  -------
sshServer              true
sshClient             false
nfsClient             false
dhcp                   true
dns                    true
snmp                   true
ntpClient             false
CIMHttpServer          true
CIMHttpsServer         true
CIMSLP                 true
iSCSI                  true
vpxHeartbeats          true
updateManager         false
faultTolerance         true
webAccess              true
vMotion                true
vSphereClient          true
activeDirectoryAll    false
NFC                    true
HBR                    true
ftpClient             false
httpClient            false
gdbserver             false
DVFilter              false
DHCPv6                false
DVSSync               false
syslog                false
IKED                  false
WOL                    true
vSPC                  false
remoteSerialPort      false
fdm                    true

To enable a specific service in the firewall, replace SERVICENAMEHERE with a service name from the previous list.

esxcli network firewall ruleset set -r SERVICENAMEHERE -e true

To disable a specific service in the firewall, replace SERVICENAMEHERE with a service name from the previous list.

esxcli network firewall ruleset set -r SERVICENAMEHERE -e false

To see the state of the firewall:

~ # esxcli network firewall get    
   Default Action: DROP
   Enabled: true
   Loaded: true

To enable the firewall:

esxcli network firewall set --default-action true

To disable the firewall:

esxcli network firewall set --default-action false

To reset the firewall after making changes:

~ # esxcli network firewall refresh

One of the most common issues people have is making sure that the correct firewall ports are opened for the tasks they are trying to accomplish.

Adding or customizing ports can be done through the Security Profile option in the vCenter or via the command line using the esxcfg-firewall command introduced in Recipe 6.11.

Table 6-2 lists the essential ports you may have to adjust in your virtual environment when troubleshooting.

Recipe 6.11

ESX 3.5/4.x ONLY - You wish to monitor and administer your servers remotely.

Use a third-party application such as Cacti, MRTG, or a commercial solution.

Turning on SNMP to monitor your ESX Servers using open source products like Cacti or MRTG, or commercial productions such as WhatsUp Pro, can provide many benefits for the health of your environment. Here’s how to enable SNMP:

You will want to verify everything you’ve done by using the snmpwalk command. This will query the snmpd process on your server and will return basic information about the system, including the kernel version, hostname, uptime, and specific information set in the /etc/snmp/snmpd.conf file, such as the Name, Contact, and Location:

snmpwalk -v 1 -c public localhost system

Output will generally appear similar to the following:

SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost.localdomain 2.4.21-57.ELvmnix #1
Wed Oct 15 19:00:05 PDT 2008 i686
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (13700) 0:02:17.00
SNMPv2-MIB::sysContact.0 = STRING: root@localhost (edit snmpd.conf)
SNMPv2-MIB::sysName.0 = STRING: localhost.localdomain
SNMPv2-MIB::sysLocation.0 = STRING: room1 (edit snmpd.conf)
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.6 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORID.7 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.9 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB module to describe generic objects for
network interface sub-layers
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.3 = STRING: The MIB module for managing TCP implementations
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for managing IP and ICMP
implementations
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing UDP implementations
SNMPv2-MIB::sysORDescr.6 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORDescr.7 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.8 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.9 = STRING: The management information definitions for the
SNMP User-based Security Model.
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.6 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.7 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.8 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.9 = Timeticks: (0) 0:00:00.00

If you run into problems, double-check your snmpd.conf file for typos, and ensure that the snmpd process is running and that your firewall ports are opened. You may also look in the /var/log/messages logfile for any errors that may have occurred.

ESX 3.5/4.x ONLY - SNMPv3 is preferred over versions 1 and 2 for security reasons. Version 3 allows for authentication between the agent and the management server, giving your SNMP traffic a more secure line of communication.

Enable SNMPv3 by editing the /etc/snmp/snmpd.conf file.

Follow these steps to enable version 3:

For detailed information on using SNMPv3, please refer to the snmpd website located at http://net-snmp.sourceforge.net.

ESX 3.5/4.x ONLY - You have a lot of users working on your servers and you want to keep track of who does what.

Using sudo, you can safely and effectively give users the ability to run certain predefined root commands with complete audit tracking.

The sudo command allows users to run commands specified in the /etc/sudoers file. Using this mechanism, you can allow normal non-root users to execute necessary commands to manage your ESX Server, without having to give them direct or complete root access.

To run a restricted command, or any command that tries to perform an activity limited to root, authorized users must preface the command with the word sudo. The first time a user does this, before the command is executed, the user will be asked for his or her regular user password. By default, sudo will automatically ask for the user’s password again if he or she attempts to execute another restricted command after a timeout period of 5 minutes. You can modify this setting by adding this variable to your /etc/sudoers file (where XX represents the value in minutes):

timestamp_timeout XX

By default, the ESX Server will use syslog to maintain logging for sudo. You can track users by looking in this file. All successful and failed sudo command attempts are logged here. However, if you want this information to be stored somewhere else, you can specify a different logfile location within the sudo configuration file by editing the /etc/sudoers file and adding a line like this:

Default logfile=/var/log/sudo.log

To get started with sudo, you will need to configure the /etc/sudoers file with the users, groups, and commands you wish to allow on your ESX Server. Although you can edit the file using your favorite editor, Linux systems also provide the visudo command specifically for that purpose. The visudo command launches vi to manage the configuration file and is the option we suggest.

When editing the sudoers file, there are a few guidelines you should follow to ensure that you use the correct syntax. We’ve compiled a short list to help you:

Recipe 6.16

ESX 3.5/4.x ONLY - Now that you have enabled sudo, you want to set it up according to your preferences.

Edit the /etc/sudoers file.

The nice thing about using sudo is that once you get a set of standards in place for your environment, adding new users, commands, or groups becomes a fairly quick process. However, setting it up initially may take some time and practice as you work out which command permissions to assign to your users.

Suppose we wanted to allow access to all root commands to a couple of users. We could do this with a line like the following:

ryan, matthew    ALL=(ALL) ALL

The real beauty of sudo, however, is its granular ability to allow users access to run only certain commands in specific locations on an ESX Server. For instance, if we wanted to grant ryan and matthew the ability to run only esxcfg commands and to restart the VMware management server, we could instead use a line like this:

ryan, matthew ALL= /usr/sbin/esxcfg-*, service mgmt-vmware restart

As mentioned in Recipe 6.15, you can also configure sudo to allow users to execute commands without having to enter their passwords. Here, we give ryan and matthew the ability to run all esxcfg commands and to restart the VMware management server, without having to enter a password by using the NOPASSWD variable:

ryan, matthew ALL= NOPASSWD: /usr/sbin/esxcfg-*, service mgmt-vmware restart

In this next example, we make ryan, matthew, and bob part of the ADMINS group and create a special ESXCMD group specifying which commands they can run. However, we disable the ability to use the su command:

Cmnd_Alias    ESXCMD = /usr/sbin/esxcfg-firewall,  /usr/bin/esxtop, 
                       /usr/sbin/esxcfginfo, /etc/init.d/mgmt-vmware


User_Alias    ADMINS = ryan, matthew, bob
ADMINS        ALL    = !/usr/bin/su, ESXCMD

This configuration is a reasonable attempt to ensure that these users cannot permanently become the root user by entering the su command. However, it doesn’t prevent them from copying files to other locations. The goal is to create a policy that lets you track what your users are doing, while staying compliant with your company’s security policies.

Sudo is a very powerful tool, and we’ve only begun to see what it can do. For more detailed information on complex setups, check out http://www.gratisoft.us/sudo/man/sudoers.html.

Recipe 6.15

ESX 3.5/4.x ONLY - There are times when you may want to monitor what a user is doing when accessing the ESX Server via SSH or directly from the console.

There are many different commands and logfiles you can use to obtain information on what users are doing, who is logging into the system, and so on.

First we’ll take a look at the logfiles, their locations, and what information they contain. There is one primary logfile that contains information about user logins: /var/log/messages. The messages logfile is a flat text file that can be searched using a command similar to the following:

grep sshd /var/log/messages

This command will search the logfile and display any lines containing the word sshd, thus telling you what your SSH users are up to. Depending on the size of your logfile, it might return a lot of information. Here is an example output from the preceding command:

Nov 10 08:25:32 esx6cluster2 sshd[30792]: Connection from 172.20.36.213 port 51085
Nov 10 08:25:35 esx6cluster2 sshd[30792]: Accepted password for root from
172.20.36.213 port 51085 ssh2
Nov 10 08:25:35 esx6cluster2 sshd(pam_unix)[30792]: session opened for user root by
(uid=0)

If you want to search for a specific user’s login, you can do this by using the same command, but adapting it slightly:

grep sshd /var/log/messages | grep bob

You can also view the last 200 lines of the messages logfile by using the following command:

tail −200 /var/log/messages

and monitor the logfile for current activity by using the following command:

tail -f /var/log/messages

Now let’s take a look at some of the commands that are available to monitor users. Linux has inherited from Unix three useful commands for this purpose: w, who, and last. These commands allow you to monitor when and from where your users are connecting, what processes they are running, and other similar information.

Let’s start with the who command. This tool allows an administrator to monitor who is connected to the system and to observe some of the characteristics relating to their connections. The who command has some useful options with which you should become familiar to help you identify users who are connected to your system.

To see a quick overview of how many users are connected to your ESX Server, run who with the -q option. If you want to see all the columns of information that the who command makes available, use the -a option (it is equivalent to specifying the options -b -d --login -p -r -t -T -u). By default, only files that are being accessed by at least one process are shown.

An example output when using the -a option might look like this:

[ryan@esx1test1 ryan]$ who -a
                        Nov 12 17:30               616 id=si    term=0 exit=0
           system boot  Nov 12 17:30
           run-level 3  Nov 12 17:30                   last=S
                        Nov 12 17:30               824 id=l3    term=0 exit=0
root     + tty1         Nov 12 20:53   .          1767
LOGIN      tty2         Nov 12 17:30              1768 id=2
LOGIN      tty3         Nov 12 17:30              1769 id=3
LOGIN      tty4         Nov 12 17:30              1770 id=4
                        Nov 12 17:30              1771 id=5
                        Nov 12 17:30              1772 id=6
ryan     + pts/0        Nov 13 13:55   .          9943 (10.0.1.200)

Looking at the output, you will see that the first four lines are related to system processes. The next line shows that the root user has logged in on the console using terminal tty1. The + character next to the username indicates that this user is able to use the write command. The following three lines, which begin with LOGIN, are login sessions that have yet to be established; they can be invoked by pressing Alt-F2, Alt-F3, and Alt-F4 at the ESX Server’s terminal.

Running the who command without any options will allow you to see a general overview of your connected users, displaying for each only the username, IP address, terminal, and connection time and date. The last line in the following output shows that root is logged in via SSH, hence the pts/0 terminal notation:

[root@esx1cluster1 root]# who
root     pts/0        Nov 13 10:44 (172.20.36.213)

Now let’s turn to the w command, an extension of the who command that displays more detailed information about the users who are connected and their current running processes. This commonly used user-tracking tool is available not only on your ESX Server, but also on most Linux platforms.

The w command has a few options that provide valuable information. Here is the output if it is run without any options:

[root@esx1cluster1 root]# w
 11:07:11  up 1 day, 45 min,  1 user,  load average: 0.23, 0.23, 0.17
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
root     pts/0    172.20.36.213    10:44am  0.00s  0.04s  0.00s  w

Notice that the w command displays more detailed information than the who command:

The first row contains the current time, the system’s uptime, how many users are connected, and the system load average for the last 1, 5, and 15 minutes. The second row contains the following information:

As you can see, the w command supplies a good amount of information on the state of your system; it is useful not just for monitoring users, but also the load and system uptime.

Finally, we’ll look at the last command. This command searches the /var/log/wtmp file and lists all of the users who have logged in and out since the file was created.

From the manpage:

As you can see, by using a combination of commands, you have complete access to data on who is logging into your system and what they are doing.

ESX 3.5/4.x ONLY - You want to enable Microsoft Active Directory on your system.

Edit the authentication configuration to use Microsoft Active Directory.

By using Microsoft Active Directory to allow your users to connect to your ESX Server via SSH, you establish a point of accountability for the user and create less work for yourself when managing users. Not all environments have a Microsoft Active Directory server, so this is an optional configuration.

To get started, log in to the console on your ESX Server as the root user, or use the su command to become the root user. Then, you will need to prepare a few things in order to set up authentication.

First, make sure your ESX Server is synced to your NTP server. If you do not have an NTP server, we suggest setting one up, because it will make using ESX much easier. If you cannot set up an NTP server, use the date command on your ESX Server, and make sure the time and date match those on your Microsoft Active Directory server.

After you’ve verified that the time is correct on both servers, use the esxcfg-auth command to configure your ESX Server to authenticate from the Active Directory server, instead of using the native Linux /etc/passwd file.

To get started, enter the following command, replacing yourdomain.com and dc.yourdomain.com with your respective Active Directory server names:

esxcfg-auth --enablead --addomain=yourdomain.com –-addc=dc.yourdomain.com

As this command runs, it will automatically configure the necessary files and services to authenticate via your Active Directory server.

For your reference, the command will edit the /etc/krb5.conf and /etcpam.d/system-auth files and will open the necessary firewall rules. You should double-check each file by running the following commands, to ensure your variables were set correctly (if not, rerun esxcfg-auth to reconfigure):

more /etc/krb5.conf

Your output will look similar to this, but with your own domain:

[domain_realm]
.yourdomain.com = YOURDOMAIN.COM
yourdomain.com = YOURDOMAIN.COM

[libdefaults]
default_realm = YOURDOMAIN.COM

[realms]
YOURDOMAIN.COM = {
        admin_server = dc.yourdomain.com:464
        default_domain = yourdomain.com
        kdc = dc.yourdomain.com:88
}

more /etc/pam.d/system-auth

When you enable Active Directory, some extra variables will be added to your system-auth file. Here’s what it looked like before:

account         required        /lib/security/$ISA/pam_unix.so

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

password        required        /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

and what it looks like after enabling Active Directory:

account         sufficient      /lib/security/$ISA/pam_krb5.so
account         required        /lib/security/$ISA/pam_unix.so

auth            required        /lib/security/$ISA/pam_env.so
auth            sufficient      /lib/security/$ISA/pam_unix.so  likeauth nullok
auth            sufficient      /lib/security/$ISA/pam_krb5.so  use_first_pass
auth            required        /lib/security/$ISA/pam_deny.so

password        required        /lib/security/$ISA/pam_cracklib.so retry=3
password   sufficient  /lib/security/$ISA/pam_unix.so  nullok use_authtok md5 shadow
password        sufficient      /lib/security/$ISA/pam_krb5.so     use_authtok
password        required        /lib/security/$ISA/pam_deny.so

session         required        /lib/security/$ISA/pam_limits.so
session         required        /lib/security/$ISA/pam_unix.so
session         sufficient      /lib/security/$ISA/pam_krb5.so

Ensure that the firewall rules are in place by issuing this command:

esxcfg-firewall -q

Essentially, when you run the esxcfg-auth command, it will add the following rules to your firewall ruleset:

esxcfg-firewall -openport 88,tcp,out,KerberosClient
esxcfg-firewall -openPort 464,tcp,out,KerberosPasswordChange
esxcfg-firewall -openport 749,tcp,out,KerberosAdm

The final step, and the only minor drawback to running authentication through your Active Directory server, is that you must create an account on the Linux server for the user who is authenticating via the Active Directory. The username you add must match the username in the Active Directory:

useradd bsmith

You do not need to set a password on this account; the system will pull the password from the Active Directory. Essentially, the username on the Linux side assigns the UID and GID, which Linux requires.

To disable Active Directory authentication, use the following command:

esxcfg-auth  --disablead

By default, the ESX Server does not explicitly set a login failure count.

Using the esxcfg-auth command, you can lock a user out of the system after too many failed log-in attempts.

To begin, connect to the ESX Server as root and issue the following command. For this example we will set the password maximum login value to 10, but you may set this variable to any number that suits your specific environment:

esxcfg-auth –-maxfailedlogins=10

Once the command has been run, you can verify it worked by running:

esxcfg-auth -p

You will see a line similar to the following in the output:

account        required    /lib/security/pam_tally.so   deny=10 no_magic_root

Notice that the deny=10 and no_magic_root variables are now set. To revert to the default settings, run the same command but replace the 10 with a 0. This will remove the entry from your /etc/pam.d/system-auth file.

ESX 3.5/4.x ONLY - You want to be certain that only certain user accounts have permission to acquire full root privileges using su.

Create a user group called wheel and configure it for access to su, adding to the group those users who need access.

The wheel group is an operating system layer group that allows a limited number of specified users to use root commands, such as the su command. Using this method should be a second choice for implementing security on your ESX Server; the preferred method is implementing sudo, as discussed earlier in this chapter.

By default, only users who are part of the wheel group have the ability to run and execute the su command. By using a combination of pluggable authentication modules (PAM) and the wheel user group, you can limit access to su by requiring users to use sudo to access root commands.

Navigate to the /etc/pam.d/ directory and look for the su file. Open this file in your preferred editor and search for the line that begins with #auth required. Remove the # character so the line reads like this:

auth required /lib/security/$ISA/pam_wheel.so use_uid

You will also need to make sure that any user you want to be able to use the su command is in the wheel group. Open up the /etc/group file with your favorite editor and look for the following line:

wheel:*:0:root

Assuming we want to give the users bob and tim access to the wheel group, we would change the line to look like this:

wheel:*:0:root,bob,tim

ESX 3.5/4.x ONLY - You want user passwords to expire after a certain time, forcing users to create new ones.

Create a password aging policy.

Because ESX is running a modified version of Red Hat Linux, we can take advantage of some of its tools to help manage users. By default, a password aging policy is set with the following parameters:

Maximum Days = 90 (default)
Minimum Days = 0 (Allows password changes to occur anytime)
Warning Time = 7 days

As you begin to look at your password aging strategy, you will most likely notice that some accounts will have no aging policy; for example, the vpxuser and root users are exempt.

The esxcfg-auth command allows you to globally set the password policy by using the --passmaxdays attribute, as you’ll see momentarily. This command offers a wide variety of options for tweaking and modifying authentication-related tasks on your ESX Server:

usage: esxcfg-auth [options]

options:
  --enablemd5           Enable MD5 password storage
  --disablemd5          Disable MD5 password storage
  --enableshadow        Enable Shadow password storage
  --disableshadow       Disable Shadow password storage
  --enablenis           Enable NIS Authentication
  --disablenis          Disable NIS Authentication
  --nisdomain=domain    Set the NIS domain
  --nisserver=server    Set the NIS server
  --enableldap          Enable LDAP User Management
  --disableldap         Disable LDAP User Management
  --enableldapauth      Enable LDAP Authentication
  --disableldapauth     Disable LDAP Authentication
  --ldapserver=server   Set the LDAP Server
  --ldapbasedn=basedn   Set the base DN for the LDAP server
  --enableldaptls       Enable TLS connections for LDAP
  --disableldaptls      Disable TLS connections for LDAP
  --enablekrb5          Enable Kererbos Authentication
  --disablekrb5         Disable Kererbos Authentication
  --krb5realm=domain    Set the Kerberos Realm
  --krb5kdc=server      Set the Kebreros Key Distribution Center
  --krb5adminserver=server
                        Set the Kerberos Admin Server
  --enablead            Enable Active Directory Authentication
  --disablead           Disable Active Directory Authentication
  --addomain=domain     Set the Active Directory Domain
  --addc=server         Set the Active Directory Domain Controller
  --usepamqc=values     Enable the pam_passwdqc module
  --usecrack=values     Enable the pam_cracklib module
  --enablecache         Enables caching of login credentials
  --disablecache        Disables caching of login credentials
  --passmaxdays=days    Set the maximum number of days a password remains valid
  --passmindays=days    Set the minimum number of days a password remains valid
  --passwarnage=days    Set the number of days a warning is given before a
                        password expires
  --maxfailedlogins=count
                        Sets the maximum number of login failures before the
                        account is locked out, setting to 0 will disable this
  -p, --probe           Print the settings to the console
  -v, --verbose         Enable verbose logging
  -h, --help            Show this help message and exit

To change the password expiration policy, use the --passmaxdays option. This will globally change the value for all new users on your system. The best practice is to set this value to 90 days. Alternatively, you can use “0” to disable the passmaxdays variable on your system globally. However, doing so will not change any current user’s password aging policy:

esxcfg-auth --passmaxdays=90   Sets the expiration to 90 days.
esxcfg-auth --passmaxdays=0    Disables system wide.

If you wish to change the password aging policy for existing users, you can do this using the chage command. For example:

chage -M −1 username    Disables aging.
chage -M 0 username     Enables aging.
chage -M 90 username    Sets to 90 days.

To view the current settings for esxcfg-auth, use the -p option. Doing so will display all the current authentication settings on your system that are managed by the esxcfg-auth command:

esxcfg-auth -p

Depending on the configuration you choose, one of seven files might be touched in the process of configuring esxcfg-auth. Let’s take a look at the files that may be affected by the esxcfg-auth command and its function. First up is /etc/krb5.conf, which contains information on your Kerberos setup:

/etc/krb5.conf


[domain_realm]
.yourdomain.com = YOURDOMAIN.COM
yourdomain.com = YOURDOMAIN.COM

[libdefaults]
default_realm = YOURDOMAIN.COM

[realms]
YOURDOMAIN.COM = {
        admin_server = dc.yourdomain.com:464
        default_domain = yourdomain.com
        kdc = dc.yourdomain.com:88
}

If you are connecting to an LDAP server, the /etc/openldap/ldap.conf file contains information on the host, base, password model, SSL, and more:

/etc/openldap/ldap.conf


base dc=example,dc=com
host 127.0.0.1
pam_password md5
ssl no

Next up is the /etc/nscd.conf file, which maintains the configuration for the name service cache daemon:

/etc/nscd.conf


    debug-level    0
    server-user    nscd

    auto-propagate group yes
    check-files    group yes
    enable-cache   group no
    negative-time-to-live    group      60
    positive-time-to-live    group      3600
    suggested-size group 211

    check-files    hosts     yes
    enable-cache   hosts     no
    negative-time-to-live    hosts      20
    positive-time-to-live    hosts      3600
    suggested-size           hosts      211

    auto-propagate passwd    yes
    check-files    passwd    yes
    enable-cache   passwd    no
    negative-time-to-live    passwd     20
    positive-time-to-live    passwd     600
    suggested-size passwd    211

The /etc/yp.conf file is called by ypbind when you are using NIS; most people won’t need to use this so we won’t list its contents here.

The /etc/login.defs file handles default permissions, group and user IDs, password expiration, and other important variables that will be used when creating a new user on your system:

/etc/login.defs


CREATE_HOME   yes
GID_MAX  60000
GID_MIN  500
MAIL_DIR /var/spool/mail
PASS_MAX_DAYS 0
PASS_MIN_DAYS 0
PASS_MIN_LEN  5
PASS_WARN_AGE 7
UID_MAX  60000
UID_MIN  500

The /etc/nsswitch.conf file contains the configuration information that NIS and LDAP use to determine information such as hostnames, password files, and group files:

/etc/nsswitch.conf


aliases:      files nisplus
automount:    files nisplus
bootparams:   nisplus [NOTFOUND=return] files
ethers:       files
group:        files
hosts:        files dns
netgroup:     nisplus
netmasks:     files
networks:     files
passwd:       files
protocols:    files
publickey:    nisplus
rpc:          files
services:     files
shadow:       files

The /etc/pam.d/system-auth file contains a central location for system wide authentication settings:

/etc/pam.d/system-auth
#%PAM-1.0


account     required      /lib/security/$ISA/pam_unix.so

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

password    required      /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

Notice that the account, auth, password, and session strings are used. The meanings of the fields in these lines depend on the module being configured.

The passmaxday value, along with other important information regarding your password aging policy, is located in the /etc/login.defs file. You should always use the esxcfg-auth command when you need to change a variable in this file. Editing it directly will result in lost settings because VMware maintains the files discussed here via esxcfg-auth and does not expect them to be modified any other way.

By default, copy and paste functionality is enabled between the guest and the host where the remote console is running. The remote console can be used via the web interface or the vCenter client. You want to prevent any applications that may be running on the host from accessing secure information stored on the guest’s clipboard.

Disable copy and paste.

Log in to your vCenter client, which should be connected either directly to the ESX Server or to the vCenter server. Make sure the virtual machine on which you wish to change the settings is powered off.

Click the virtual machine, then click Edit Settings, followed by Options, and finally General, which is located under Advanced. From here, click Configuration Parameters, which will open a new dialog box containing advanced options.

Add the following parameters and set the values accordingly:

isolation.tools.copy.disable = true
isolation.tools.paste.disable = true
isolation.tools.setGUIOptions.enable = false

Once you’ve made these modifications, close the windows to save the configuration. Because these values get written to the virtual machine’s .vmx file, they won’t take effect until you restart the virtual machine.

A default installation of the VMware tools will allow you to shrink a virtual machine’s disk. The problem with leaving this option enabled is that any users, regardless of their permissions on the virtual machine, will be able to resize the virtual machine’s disk.

By adding a few configuration parameters, you can ensure that your users cannot shrink the virtual machine’s disk, thereby guaranteeing that it works at its maximum potential and limiting the possibility of the virtual machine becoming unavailable.

To begin, log in to your vCenter client, which should be connected either directly to the ESX Server or to the vCenter server. Your virtual machine will need to be powered off.

Click the virtual machine, then click Edit Settings, followed by Options, and finally General, which is located under Advanced. From here, click Configuration Parameters, which will open a new dialog box containing advanced options.

Add the following parameters and set the values accordingly:

isolation.tools.diskWiper.disable = True
isolation.tools.diskShrink.disable = True

Once you’ve added the new variables, restart the virtual machine so that they will become active. If you want to resize your disks in the future using the VMware Tools, you can reset these values to False or remove them.

When creating a new virtual machine, or doing a physical-to-virtual (p2v) conversion, you want to avoid adding unneeded devices that are not often used in a virtual environment, such as USB devices, floppy drives, parallel ports, and serial ports.

Edit the virtual machine settings as necessary.

When you create a new virtual machine, you can choose whether or not to include these types of extra devices. However, when you do a p2v conversion, any hardware on the physical server will be replicated to the new virtual machine. Before powering on your new p2v-converted server, you may wish to use the vCenter to remove any unneeded devices.

Log in to your vCenter server and select the virtual machine you wish to modify, right-click on it, and choose Edit Settings. You will be prompted with the devices that are currently attached to your virtual machine; adjust them as needed.

By default, users can use the VMware Tools to disconnect connected devices like CD-ROMs and Ethernet adapters. This can cause problems if the user has used the CD-ROM to install applications, or disconnects an Ethernet adapter and takes the virtual machine off the network.

To limit access to these features, set specific variables in the .vmx file. This can be accomplished using the vCenter.

To begin, log in to your vCenter client, which should be connected either directly to the ESX Server or to the vCenter server. Make sure the virtual machine on which you wish to change the settings is powered off.

Click the virtual machine, then click Edit Settings, followed by Options, and finally General, which is located under Advanced. From here, click Configuration Parameters, which will open a new dialog box containing advanced options.

You will need to add the following parameters and set the values accordingly:

isolation.device.connectable.disable = TRUE
isolation.device.edit.disable = TRUE
Isolation.tools.connectable.disable = TRUE

Once the new variables have been added, you will need to restart the virtual machine for them to become active. You may disable these settings in the future by using the VMware Tools to either set the parameters to False or to remove them.

You wish to disable the option of allowing VMware Tools to make overriding modifications to variables that are managed on the ESX Server, ensuring that users cannot make configuration changes or bypass rules you have already established.

Adjust the settings in the configuration file.

To begin, log in to your vCenter client, which should be connected either directly to the ESX Server or to the vCenter server. Make sure the virtual machine on which you wish to change the settings is powered off.

Click the virtual machine, then click Edit Settings, followed by Options, and finally General, which is located under Advanced. From here, click Configuration Parameters, which will open a new dialog box containing advanced options.

Look for the following value and set it to false if it’s currently set to true. If it is not present, you can add it by clicking the Add Row option:

isolation.tools.setGUIOptions.enable = false

Restart the virtual machine so that your changes take effect.