Yellow Bricks

by Duncan Epping

security

Tripwire Configcheck

· ·

When I published my article on tools/scripts I use during a VMware Healthcheck I received a couple of emails on Tripwire’s Configcheck. I’ve been on a holiday for a couple of weeks so it took me a bit longer than usual to check out the product.

Configcheck can be downloaded for free. Configcheck is a Java Application so you will need to install JRE. Installing JRE can be a bit of a pain sometimes on a server so this is one of the reasons for me that will make it hard to actively use Configcheck at customer sites. (This depends on the customers policy.) Installing the product is fairly easy though:

  1. Download Java JRE.
  2. Download the file configcheck.zip to a Windows machine that has Java Runtime Environment (JRE) version 1.5, or higher.
  3. Unzip the configcheck.zip file

That’s it, fairly easy. Now you can run “configcheck.cmd” to check the specified ESX host on security issues. Once the check is complete you can click the test results to view remediation steps. The test results will look like this:

As you can see, 37 Passed and 40 Failed. Not really surprising considering the fact that I ran this against a newly build ESX 3.5 U3 host. No modifications whatsoever. Clicking the test results didn’t work on my test servers because of the lack of an internet connection. Unfortunately it’s also not possible to export the data in this version. It’s free and Tripwire’s Enterprise edition does give you this capability, if you need export and a whole lot more check it out. You can find a data-sheet with a comparison between Configcheck and enterprise here.

Luckily Tripwire also provides the remediation steps in pdf form. For instance the remediation steps for 1.2.2 “Verify the log files to keep is equal to 10”:

Description: 
This test determines if virtual machines are configured to keep 10 log files when the recommended log rotate size of 100KB is exceeded. Virtual machines log activity in their respective vmware.log files. If growth of these log files is not limited, it is possible for virtual machines to cause a denial of service on the ESX Server by filling up the VMFS volume. There are two options for preventing virtual machines from flooding the hard disk of the host: size-based log file rotation or disabling logging for the virtual machine. This policy checks for size-based log file rotation because disabling logging altogether limits troubleshooting options.

Remediation:
To remediate failure of this policy test, configure the virtual machine to keep 10 log files when the recommended log rotate size of 100KB is exceeded. Configuring the virtual machine to keep 10 log files when the recommended log rotate size of 100KB is exceeded:

Login to the VirtualCenter or use the VI Client to connect directly to the ESX Server hosting the improperly configured virtual machine.

  1. Power off the virtual machine if needed.
  2. Right click the virtual machine and click Edit Settings.
  3. Select the Options tab.
  4. Select Advanced > General, and click the Configuration Parameters button.
  5. Look for a row with log.keepOld and set the value to 10.
  6. If the row does not exist, then click the Add Row button.
  7. In the Name field type log.keepOld.
  8. In the Value field type the value to 10.
  9. Click OK to close the Configuration Parameters dialog.
  10. Click OK to close the Virtual Machine Properties dialog.
As you can see, the description and remediation explain why and what to do in a fairly extensive manner. Which is great cause not does this make solving the “problem” really easy, Tripwire’s Configcheck also educates the SysAdmin!

Adding users + roles with powershell

· ·

So you can easily add users with useradd command we talked about. But there’s still a problem, you can’t add user-roles to the user you’re creating. You still need the VirtualCenter client to do that. My colleague Horst Mundt read my post and was so kind to email me a powershell script he created that can add roles to specific users or groups for you:

$VCimpl = Get-VIServer -Server 192.168.116.201 -User root -Password <...>
# Note: Server is an ESX host, not VC
# Force load
[Reflection.Assembly]::LoadWithPartialName("vmware.vim")

# Edit hostname below
$hostname = "esx302.hm.local" 

# The name of the role to be assigned
$roleLabel="Read-Only"
#$roleLabel="Administrator"

#The name of the principal (user or group) that the role is assigned to
$principal="GroupX"

# set to false if principal is a user , not a group
$principalIsGroup = $true

$propagateToSubEntities = $true

$svcRef = new-object VMware.Vim.ManagedObjectReference 
$svcRef.Type = "ServiceInstance" 
$svcRef.Value = "ServiceInstance" 
$serviceInstance = get-view $svcRef

$authMgr = Get-View $serviceInstance.Content.AuthorizationManager
$hahost = Get-View (Get-VMhost -Name $hostname).ID
$compResource = $hahost.Parent
$oldperms = $authMgr.retrieveEntityPermissions($hahost.MoRef, $true)
$roles = $authMgr.roleList
$roleid = 0
$found = $false
for ($i = 0 ; $i -lt $roles.Length ; $i++)
{
      $role=$roles[$i]
      if ($role.Info.Label -eq $roleLabel)
      {
            $roleid = $role.RoleId
            $found = $true
      }
}
if ( $found -eq $false )
{
      echo ("Role not found: " + $roleLabel )
      exit 1
}

$permission = New-Object Vmware.Vim.Permission
$permission.group = $principalIsGroup
$permission.principal = $principal
$permission.propagate = $propagateToSubEntities
$permission.roleID = $roleid
$authmgr.SetEntityPermissions($compResource, @($permission))

The script has been tested on ESX 3.0.2. I did not have the opportunity to test it myself by the way… So if anyone can test it against ESX 3.5 and let’s us know what the results are!

Additional user account in a scripted install

· ·

When doing a scripted install it might be useful to create additional user accounts. You can easily do this with the following command:

/usr/sbin/useradd -m -p ‘\$1$ZRo.R0\$1Lk8iA0AaqVFlojm.BTmr/’ -c administrator -g users -G users -d /home/administrator -s /bin/bash administrator

The “-p” value is the encrypted password. You can create them by using the tool “grub-md5-crypt” on a linux box. Just type “grub-md5-crypt” and type your password twice and it returns a md5 encrypted password which you can use in your scripted install. Keep in mind that there can be special characters in your password, if you do a scripted install this will be misinterpreted and you these characters need a preceding “\”.

Where’s my lockdown mode in ESX 3.5?

· ·

I’ve been looking for the lockdown option in ESX 3.5 for a few of hours these last couple of days and can’t seem to find it. In ESX 3i you can easily put it in lockdown mode when you add the host to the Cluster or afterwards here in the configuration/security section:

After a search on the internet is seemed I wasn’t the only that could not find the lockdown mode for 3.5. Viktor van den Berg opened a topic about it on the Dutch VMUG forum and decided to phone VMware about it… There answer was short, it’s not in 3.5 and it should have been. I guess it got lost in cyberspace.

For those who never heard of the lockdown mode:

VirtualCenter 2.5 provides administrators with the option to disable direct remote access to ESX Server 3 hosts as a root user after VirtualCenter 2.5 has taken control of a given host. This is called “lockdown mode.” Enabling this mode ensures that the host is managed only through VirtualCenter 2.5. Certain limited management tasks can still be performed while in lockdown mode by logging in to the local console on the host as a non-root user.

I guess we just have to wait for the upcoming patches.